Observing the electrical behaviour of a NMEA 2000 network

Earlier I wrote that I was going to investigate why Simrad/Navico is now advocating adding a Simnet Noise Filter to more complicated networks.

First I measured a small bench network using Simnet cable at home.

A screenshot of a simple network (one sender, one Actisense NGT-1 and about 5 m of cable in total, with no terminators. I was expecting swinging of the observed signal when it returns the bus to a non-driven state, and indeed the digital scope proves it worth and shows this to good effect. As you can see, the rising edge when the sender drives the bus the wave is pretty neat. The swinging happens when the sender stops driving the CAN output driver and the voltage returns to zero, with quite large oscillations around 0 V.

Adding a 68 Ohm resistor (which is the nearest equivalent of 2 x 120 Ohm terminators) results in the picture shown here at the right. As you can see the ringing is a lot less now.

Then I added 40 m of Simnet cable:
As was expected, this added a bit of capacitance to the cable: the rising flank of the pulses aren't straight up anymore, especially once the voltage reaches 2,5 V, and the ringing is back. I didn't expect that.

And finally I switched to a 39 Ohm terminator, which is what you end up when you install a 'Simnet Noise Filter' at the mast base which is what Simrad is telling me to do. We now get a bit of overshoot on the rising flank as well, and you can see the slower and reduced ringing because of the changed impedance.

Last weekend I finally had the chance to measure my own boat's onboard network, which has a what I'd call decent mid-level network with 13 active senders and about 60 m of cable. The added load of the devices and longer cable results in a cleaner waveform. Nothing really wrong here, but still there is a bit of overshoot on the rising signal.

The last image is of course with the filter installed. The effects seen in the test network were seen again. No overshoot or ringing; this is now completely gone. The rise and fall time is still completely acceptable.

The noise filter also has as an added benefit that the network will work more reliably when the cable going up the mast to the wind sensor is removed, either because accidentally or on purpose.

Conclusion

The Simnet Noise Filter seems to work and improve the signal behavior of the two networks that I tested it on, and I intend to keep it installed. It is recommended for large(r) Simnet networks.

It would be interesting to see the effect of such a network on other brands of NMEA 2000 cable.

Chetco SeaSmart

Panbo has an item on the new Chetco SeaSmart Serial, Wifi and Ethernet devices.

These seem to be nicely wrapped-up versions of the N2K to Ethernet bridge that has been talked about and that I've been writing myself for my own use.

At the moment the specifications on the protocol are still quite vague, and contain strange terminology (as Jeff Siegel pointed out on Panbo) where they talk about "HTTP Header" that looks like a reference to a NMEA 0183 style message ($Pxxxxx).

Whatever their protocol is going to be, it looks interesting enough to add such a protocol to my NMEA0183 forwarder and integrate it with my NMEA2000 packetlogger application.

NMEA 2000 connector pinout - Smart!

Today my attention fell to this diagram in a NMEA 2000 device manual from Maretron:

As you can see the pin-out is:

Pin 1	Shield	-	Shield
Pin 2	Red	NET-S	+12V
Pin 3	Black	NET-C	0V
Pin 4	White	NET-H	CAN-H (data high)
Pin 5	Blue	NET-L	CAN-L (data low)

I noticed that the center pin is not carrying ground or even shield, which I naively thought would be the case. In fact the designers of this pin-out were a lot smarter! As this is a circular connector, a dumb user could theoretically try to push two connectors together whilst forcing a wrong orientation. That would force power down the wrong wires.

Let's see what happens if you rotate the connectors:

Female	Male 90°	Male 180°	Male 270°
Shield	+12V	0V	CAN-H>
+12V	0V	CAN-H>	Shield
0V	CAN-H	Shield	+12V
CAN-H	Shield	+12V	0V

The chosen layout ensures that you never wire up +12V or -12V to the two data connections, as at no point is CAN-L involved.

If the wiring is such that Shield is connected to common (0V) then the fuse will blow in the 90° orientation; it will always blow in the 270° case and nothing bad should happen in the 180° case.

Cool!

Simnet Noise Filter

Recently I became aware of the fact that (a) Simrad has switched to a new specification for their Simnet cabling and (b) that there is a "Simrad Noise Filter" that they recommend for installation in sailing boats.

As you can see here in an report from Ben @ Panbo on N2K cable mixing, Simnet cables used to contain a yellow/blue pair for the data wires. Apparently this type of cable caused issues as the impedance of a long stretch was not according to NMEA specifications. This naturally ends up giving problems when you have a IS 20 wind instrument at the other end of a 20m cable. In my case it's even worse as I had to order a 30m cable as my mast is 25m tall.

I've been told that Simrad has switched to a different cable that has white/blue data wires which has better characteristics. To 'fix' existing installations Simrad has also produced a "Simnet Noise Filter", P/N 24006934. The Simrad NSE documentation states on PDF page 32:

For a large systems or sailboats with a mast head wind sensor and long mast cable, it is recommended to use a SimNet noise filter (24006934). On sail boats the filter should be inserted at the mast junction. On larger systems without a mast head unit, the filter should be inserted centrally along the backbone.

The original 2006 era SimNet installation manual contains no reference to this. Probably these issues have become more prevalent with larger networks being deployed.

I've ordered such a noise filter. I've been told it contains a 120 Ohm termination resistor as well as a 220 μF capacitor to damp out supply issues. Once it gets delivered I'll report on what it contains and the effects on my network.

Packetlogger update with fixed field lengths and lookup values

The NMEA has in the past decided to keep the NMEA 2000 PGN database private. To get access to the database you need to become a member of the NMEA or buy the standard outright. Appendix B is $900. And, as of recent, this is not enough as the NMEA is now desupporting PGNs in favour of SAE standards that require you to buy SAE standards as well.

The money for the standards in itself is not so much a problem as is the fact that if you buy it you are not allowed to publish the data contained in the standard.

The best unencumbered source for NMEA 2000 data that I have found so far is the NMEA 2000 database in Vector's CANalyzer / CANoe demo product that you can download here. It does seem to contain a slightly older version of the NMEA database as not all fields described by the NMEA are present.

It is a pity that the various industry bodies keep insisting on non-free standards. It is my belief that open standards such as the Internet standards which are published by the IETF using the RFC process form a better way to promote standard adoption.

Anyway, using the data mentioned above I have been able to confirm a lot of guesses that I had already made earlier, and fix some other fields. In particular the lookup values of a lot of fields have seen significant improvements. I have also been able to determine field lengths for PGNs and fields that I do not have logs for.

The analyzer now does correct decoding of everything that I have seen in the field through my own logfiles and those that have been sent to me, as far as I can see.

As usual, you can download the NMEA analysis + reader programs here.

The complete list of improvements:

• All field lengths of NMEA PGNs should be correct.
• All field descriptions of NMEA PGNs with lookup values should be correct.
• The XML file now also mentions whether a field is signed or unsigned.
• The XML file now describes the real NMEA 2000 field type, not the converted type. For instance, the analyzer converts radians to degrees as these are more 'natural' for humans to understand. Previously those fields were described as being in 'degrees', now the correct unit is given as 'rad', and the resolution is also given with the correct magnitude.
• The analyzer now correctly decodes signed integer fields such as the time offset in minutes in PGN 129033.
• The database now knows about IEEE float data fields. The analyzer cannot print these out yet as I have no samples of this data yet.
• Initial support for Darwin (Mac OS X). The analyzer works very well. I've ported the serial port reader programs as well, but the actisense-serial program does not seem to want to read from the serial port as presented by Actisense's OS X drivers yet.

As of now I am no longer in need of unqualified log files. You still can and should send me a log file if you see a PGN that the analyzer decodes incorrectly, of course.

Code for converting a CAN message ID to ISO 11783 / NMEA 2000 fields

I've received a number of requests from people who are trying to get microcontrollers up & running that they want to attach to the N2K bus.

Apart from the logical content of the datafields for each PGN, one of the other things that you will end up doing is filtering out the priority, PGN, source address and destination address from the underlying CAN message.

NMEA 2000 messages are always CAN 2.0B messages with the "Extended Frame" format. It uses the ISO-11783 standard as the physical layer. That standard is where we get the "PGN" term from.

Once you get a ISO-11783 CAN message ID from your device, it will contain an encoding for the PGN number, the priority, the source ID and possibly a destination address. To save bits the PGNs that are not addressable imply a "broadcast" destination of 255. That format is called PDU2. Other PGNs are addressable, and contain an explicit 8 bit destination in the PS field. That format is called PDU1. If you want to know more, try googling for ISO11783 PDU1 for more information.

Once you've got the 32 bit CAN message ID (which you should be able to get from your hardware device pretty easily) you need to convert the message ID to priority, PGN, source and destination. Here is the source code that I came up with to do this:

static void getISO11783BitsFromCanId(unsigned int id, unsigned int * prio, unsigned int * pgn, unsigned int * src, unsigned int * dst)
{
  unsigned char PF = (unsigned char) (id >> 16);
  unsigned char PS = (unsigned char) (id >> 8);
  unsigned char DP = (unsigned char) (id >> 24) & 1;

  if (src)
  {
    *src = (unsigned char) id >> 0;
  }
  if (prio)
  {
    *prio = (unsigned char) ((id >> 26) & 0x7);
  }

  if (PF < 240)
  {
    /* PDU1 format, the PS contains the destination address */
    if (dst)
    {
      *dst = PS;
    }
    if (pgn)
    {
      *pgn = (DP << 16) + (PF << 8);
    }
  }
  else
  {
    /* PDU2 format, the destination is implied global and the PGN is extended */
    if (dst)
    {
      *dst = 0xff;
    }
    if (pgn)
    {
      *pgn = (DP << 16) + (PF << 8) + PS;
    }
  }

}

NMEA2000 support and DSC calls on a Simrad RS82/87

Yesterday I received an email query from someone who wanted to know whether a Simrad RS82 will put out the DSC Call Information, PGN 129808. As I had to visit the boat anyway I was able to run a small test by making an individual DSC call to my own VHF from someone else's RS82.

The good news is that making an individual DSC call is very simple, at least on a RS82, and I will definitely use this capability more often now that I have been reminded how simple it is.

The bad news is that, at least with the software version I've got in my RS82, it does not transmit the NMEA 2000 standard PGN but a Simrad specific PGN 130816. It is clearly a PGN that was defined early on in Simrad's Simnet/NMEA2000 adoption cycle as it is very much text based whereas all standard PGNs are all very much binary field based. This did make it very easy for me to add support for this PGN (although a few minor fields are still guesses on my part).

Here is an example of the PGN 130816 in action:

2010-09-14-16:53:05.600 3   9 255 130816 Simrad: Text Message:  Manufacturer Code = Simrad; Industry Code = 19; Product Code = 16393; A = 156; B = 1; C = 1; D = 7; SID = 1; Text = INDIVIDUAL CALL
2010-09-14-16:53:05.711 3   9 255 130816 Simrad: Text Message:  Manufacturer Code = Simrad; Industry Code = 19; Product Code = 16393; A = 92; B = 1; C = 1; D = 7; SID = 2; Text = RECEIVED FROM RS81/82
2010-09-14-16:53:05.805 3   9 255 130816 Simrad: Text Message:  Manufacturer Code = Simrad; Industry Code = 19; Product Code = 16393; A = 92; B = 1; C = 1; D = 7; SID = 3; Text = CALLER ID: 244087177
2010-09-14-16:53:05.879 3   9 255 130816 Simrad: Text Message:  Manufacturer Code = Simrad; Industry Code = 19; Product Code = 16393; A = 92; B = 1; C = 1; D = 7; SID = 4; Text = CATEGORY: INDIVIDUAL
2010-09-14-16:53:05.990 6   9  36  59904 ISO Request:  PGN = 60928
2010-09-14-16:53:05.994 3   9 255 130816 Simrad: Text Message:  Manufacturer Code = Simrad; Industry Code = 19; Product Code = 16393; A = 92; B = 1; C = 1; D = 7; SID = 5; Text = REPLY ON CHANNEL 77
2010-09-14-16:53:06.088 3   9 255 130816 Simrad: Text Message:  Manufacturer Code = Simrad; Industry Code = 19; Product Code = 16393; A = 84; B = 1; C = 1; D = 7; SID = 6; Prio = 1; Text = STOP ALARM: SELECT CHANNEL 77
2010-09-14-16:53:06.166 3   9 255 130816 Simrad: Text Message:  Manufacturer Code = Simrad; Industry Code = 19; Product Code = 16393; A = 84; B = 1; C = 1; D = 7; SID = 7; Prio = 2; Text = STOP ALARM

Note that the information in the call did not contain GPS position. Unfortunately I forgot to wait for the sending VHF to obtain a GPS position, so I have no idea what will be sent out when that does transmit a location.

If someone knows whether my guess at the 'Product Code' and 'Prio' fields are correct, and what the meaning of fields A, B, C and D is then please do tell.

And if you have a RS8x with newer software than me and are able to test DSC calls, or know whether its software can be updated know whether SW version 2.3 provides any updates in this area then I'm all ears.

The new packetlogger can be downloaded at the usual place.

Packetlogger update for Raymarine E-80, Lowrance EP-80R

Thanks to some enterprising folks I received a few log files from other equipment such as a Raymarine E-80 and this has resulted in another release of the packetlogger programs and database.

Some data analysis of the logs enabled me to fix the field lengths and types of a number of PGNs, like the Set & Drift data, add Lowrance specific PGNs 65285 and 130817 as sent out by a EP-80R, and confirm a number of PGNs are correct. As a result a lot more PGNs are now considered 'complete'. That means there is a high probability they are now decoded completely and fully.

You can download the latest packetlogger release at the usual place.

Keep those log files coming! I'm especially interested in logs from new equipment such as the latest generation of MFDs from Raymarine and ANY logs from Furuno and Garmin equipment.

And on a side note, be careful if you expect a Lowrance EP-80R temperature probe to interoperate with non-Lowrance equipment. Based on the data I received, there is at least one version out there (with firmware release LA53D dated 2/7/2007 10:47:53 AM) that does not transmit the NMEA standard PGN for temperature, but only a Lowrance PGN. If you intend to interoperate, make sure you get one that you can return if it is not satisfactory. Hopefully this problem has been fixed in a later firmware release.

Your Help Needed to firm up the NMEA 2000 database

My reverse-engineered database of NMEA 2000 data is getting pretty good at reading NMEA 2000 data. The 'standard' depth/speed/temperature, GPS and AIS messages are all parsed pretty well now.

What is still in a nature of flux are the more 'outlying' messages such as DC/AC control, the ISO commands, configuration commands and the manufacturer proprietary commands.

I will work up the Simnet/Navico/Lowrance proprietary commands myself over time, as my network has those in abundance.

The nature of reverse engineering does mean that it is not possible for me to be 100% sure of messages being correct until I have manually compared the raw data with known data, but it will help if you send me logfiles of the 'raw' data logged by the reader programs of your own bus, especially if it contains devices I haven't be able to get my hands on yet.

Here is a list of devices that I have logfiles for already. If you have anything NOT on this list, please make a log and send it to me in compressed (zip or gzip) format. The best logs are those that show all messages from 'start' of the bus. Unless I ask you for more, or you want to show me AIS sentences that the software doesn't analyze correctly, about 30 seconds of log will do.

• Airmar DST200 sensor
• Airmar PB200 sensor
• Lowrance HDS8
• Lowrance EP65R sensor
• Mastervolt NMEA2000/Masterbus converter
• Navico NAIS300 AIS
• Simrad AT10 NMEA converter
• Simrad AC42 autopilot computer
• Simrad AP24 AP control head
• Simrad IS20 Wind display
• Simrad IS20 Wind display
• Simrad IS20 Wind display
• Simrad IS20 Wind sensor
• Simrad RC42 compass sensor
• Simrad RS82 VHF
• Simrad WR20 Remote

To create a logfile, do the following on Microsoft Windows in a command prompt window after unpacking the latest packetlogger code:

C:\packetlogger\win32> actisense-reader
Usage: actisense-reader <com-port> [<baud-rate>]

<com-port> is an integer from the following list:
3: COM3 - Actisense NGW/NGT NMEA 2000 Gateway (Available)

<baud-rate> is an integer from the following list:
4800 38400 115200 230400 (default is 115200)

C:\packetlogger\win32> actisense-reader 3 > my-small-or-big-boat-logfile.log

Note that the first command shows you a list of all COM ports. It should show you which COM port the Actisense device is using. Choose the number for that port in the second command. Let it run for a few seconds, then press Control-C to stop the reader. Zip up the file.

On Linux, the comparable action is:

$ actisense-serial /dev/ttyUSB0 | gzip > my-small-or-big-boat-logfile.log.gz

Thanks!

Packetlogger update: PGN list complete, Linux version available

I'm back from finishing a boat, testing it by sailing to Denmark and then showing it at the HISWA boat show.

Now is the time to catch up with my backlog here. Let's start off with an update to the packetlogger utility. The new 'Summer 2010' release out now has a ton of improvements.

You can download the packetlogger here.

The improvements made are:

• The code now knows about all official PGNs as the NMEA has released the complete list of PGNs and field descrioptions. Unfortunately, that list does not contain field sizes, lookup values or other information but it still helped a lot with my understanding some of the PGNs.
  
• Linux binaries are included for x86. It was compiled on a Debian 5 release, so it should run on all recent Linux distributions. The Linux port also includes an Actisense NGT-1 reader, which was developed with the kind support of Actisense.
• The code now understands PGNs with repeating fields a lot better. Some PGNs have a variable list of fields, with the last few fields repeating a number of times.
• Add a json option to the analyzer so the output can be fed to web-oriented languages such as Perl, PHP and Javascript with ease.
• Log the manufacturer for all manufacturer specific PGNs.
• Remove explicit empty PGNs that we only knew the manufacturer for.
• Verified that the Mastervolt NMEA 2000 interface is compatible.

This should keep many folks happy for a while. Keep the feedback coming, by private email is fine if you don't want to show up here.

Airmar PB200 WeatherStation power usage

I've measured actual power usage for the expensive but all-encompassing-all-but-dancing-and-singing Airmar PB200 WeatherStation NMEA 2000 sensor.

It is officially stated as a 13 LEN device which means that it could use up to 13 * 50 = 650 mA @ 12 V = 7 W, but it actually only uses 2.5 W, e.g. 4 to 5 LEN. That's OK for a sensor that does all of the following:

• GPS (WAAS, EGNOS) (it even claims to do GLONASS according to its PGN 12029)
• Heading (rate stabilised)
• Pitch & Roll
• Wind direction and speed
• Temperature
• Air pressure

Airmar PB200 support for Packetlogger

A new release for packetlogger, with support for the PGNs created by the Airmar PB200 Weatherstation.

I've added support for the following NMEA 2000 data fields and records (PGNs):

• PGN 65410 (Airmar Device Information, 90%)
• PGN 126988 (Configuration Information, 90%)
• PGN 127251 (Rate of Turn, 99%)
• PGN 127257 (Attitude, 99%)
• PGN 129034 (Datum, 50%)
• PGN 130311 (Environmental Parameters, 90%)
• PGN 130323 (Meteorological Station Data, 90%)
• PGN 130880 (Airmar: Additional Weather Data, 90%)
• PGN 130881 (Airmar: Heater Control, 60%)
• PGN 130944 (Airmar: POST, name only)

The files can be downloaded here:

• packetlogger_20091015.zip
• packetlogger_20091015_explain.txt
• packetlogger_20091015_explain.xml

General fixes for packetlogger

Here is another release of the packetlogger suite.

Bug fixes:
- Better operation with fields that are stored in non-8-bit quantities.
- Fixed long format reading -- e.g. all data generated by Airmar WeatherCaster and actisense-reader. This fixes the issues with PGN 129029 and others.
- Fixed geographical positions on southern and western hemispheres.

New features:
- Allow explanation of understood NMEA 2000 data fields and records (PGNs) in XML format (by request).
- Allow insight into which bits and bytes are used for which field (-debug option).
- Allow output of geographical coordinates in DD, DM and DMS formats. DD format can be sent straight to Google Maps (-geo dd|dm|dms option).
- Include vcredist_x86.exe for those running older Microsoft Windows versions that don't have the requisite files. Run vcredist_x86.exe when you have trouble running actisense-reader and/or lawicel-reader.

Notes:
- You still need to install the Actisense or Lawicel device drivers, these are not included. Nothing is needed to run analyzer.exe by itself.

Download here:

• packetlogger_20090806.zip
• packetlogger_20090806_explain.txt
• packetlogger_20090806_explain.xml

Actisense NGT-1 update for packetlogger

Last week I received a NGT-1-USB that Actisense kindly provided for a trial here in the lab. It is a much more capable device than the Lawicel CANUSB that I have been using so far, as it relieves the burden of the programmer of having to negiotate bus commands. As a drawback its SDK is more complicated -- primarily because it supports multiple Actisense devices. Still, I'm very satisfied and if I can write a Linux driver I'll keep it (and pay for it!)

Anyway, I have now updated the packetlogger so that it can use the Actisense NGT-1 or NGT-1-USB for sniffing NMEA 2000 packets. As the NGT-1 already does fast packet assembly I had to modify my analyzer and support a new packet format for the logger. The analyzer will transparently adapt to the new format. The existing 'canreader.exe' program has been renamed 'lawicel-reader.exe' and a new 'actisense-reader.exe' has been added.

The actisense reader needs to know which virtual COM port the Actisense device is on. To find out which port that is you run actisense-reader without any arguments, like this:

C:\packetlogger> actisense-reader
Usage: actisense-reader <com-port>

<com-port> is an integer from the following list:
3: COM3 - Actisense NGW/NGT NMEA 2000 Gateway (Available)

<baud-rate> is an integer from the following list:
4800 38400 115200 230400 (default is 115200)

If your device still has the original baudrate (115,200) you do no need to provide this as it is the default value.


The work done to support the Actisense NGT-1(-USB) turned out to be most of the work needed to support the logfiles that Airmar's WeatherCaster software can create, so I've added support for those as well. Note that the WeatherCaster software, although not very flexible, is useful even if you do not own a Airmar PB-200. It can show other (wind, speed, GPS) data as well.

Here are the links to the new software and NMEA packet support files:

• packetlogger_20090628.zip
• packetlogger_20090628_explain.txt

Oh, and as a final bonus I've located some more PGN numbers, so these are now displayed as well. Most of them seem pretty obscure and I haven't seen them on my network at all. Still, when they come by you will know what the packet name is.

AIS class B update for packetlogger

Last week Ben Ellison at Panbo found that there is no AIS class B static data PGN agreed upon yet so when you connect a Navico NAIS-300 to a Garmin display there is no class B static data shown. As you can see in his NMEA 2000 PGN received list the NAIS-300 puts out a Navico specific PGN: 130842.

As I had a few days on the boat with the kids I dragged my NMEA 2000 network to the boat and rigged up a temporary network to verify some things. One reason was to see if I stumbled upon a Class B sender so I had some packets to analyze. Luckily I found one willing Class B sender half way down the IJsselmeer. This showed up nicely on the Lowrance HDS-8 that showed all this on the Info display shown up right. Side note: making pictures of displays out in the sunshine is harder than I thought. Weird how that dust shows up prominently on the photo, it was absolutely not irritating in the real world.

As a result I can verify that the Navico PGN 130842 does indeed contain the missing Class B static data: call sign, vessel type, dimensions. There are some other fields as well, but I can't yet place those. Interestingly, the PGN 130842 is transmitted every 6 minutes (on receipt of the over-the-air AIS message 24 Class B CS static data report) and then twice in succession, each with different length and somewhat different data.

The first format is 37 bytes long, and an example is (first in hex bytes, then ascii, then what I can make of it):

41 9F 81 FF 18 0F EA 8B 0E 25 54 52 55 45 48 44 47 50 45 34 32 35 38 00 6E 00 28 00 14 00 6E 00 FF FF FF FF C0

A . . . . . . . . . T R U E H D G P E 4 2 5 8 . n . . . . . n . . . . . .

A = 65 B = 159 C = 129 E = 24 MMSI = 244050447 Type of ship = Pleasure F = TRUEHDG Callsign = PE4258 Length = 11 m Beam = 4 m GPS from port = 2 m GPS from bow = 11 m L = 192

The second format is 29 bytes long, and an example in the same formats is:

41 9F 80 FF 18 0F EA 8B 0E 50 41 56 41 4E 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00

A . . . . . . . . P A V A N E . . . . . . . . . . . . . .

A = 65 B = 159 C = 128 E = 24 MMSI = 244050447 Name= PAVANE

Note the peculiar string embedded in the first format: TRUEHDG. This is likely to indicate that this NAIS-300 is based on a design from True Heading. After opening the case I did indeed find one Navico and one SRT circuit board, linked with a single four wire interconnect. The Navico specific board is much simpler, and only contains a smallish microprocessor. The SRT board contains a massive ASIC and a Texas Instruments 320Cxx class CPU, memory etc.

This seems to indicate that the communication between the two boards is a simple serial protocol, and that the Navico board only serves as the power circuit and NMEA 2000 interface.

The packetlogger program now understands the above forms of PGN 130842 as well as PGN 129039 (Class B position report) and can be downloaded from here. The list of messages and fields understood can be downloaded as well.

Packetlogger update

The packetlogger suite (v20090607) can be downloaded here. It still requires a Lawicel CANUSB device to sniff new data from the NMEA 2000 bus, but it is now split into two parts: the actual "sniffer" called canreader.exe that talks to the bus, and a separate analyzer called analyzer.exe.

Both programs operate in UNIX filter style; canreader can only log CAN data to stdout. It runs until a line is entered on stdin. analyzer reads stdin and write analyzed output to stdout.

Analyzer can run without a CANusb present. Without raw N2K log files though the only thing it can do is show what NMEA PGNs and fields therein the program understands.

Here are some typical usage examples:

analyze -explain # Show what PGNs are understood by the program

canreader | analyzer # read data and analyze immediately

canreader > rawnmea.log # write data that can be analyzed at a later date

cat rawnmea.log | analyze -raw -data # interpret file later date, show three stages of interpreted data

cat rawnmea.log | analyze 129038 # focus on single PGN

Here is a link to the output of analyze -explain that shows the current list of supported PGNs.

PGNs that have improved in this release:

• 127505 - Fluid Level (now complete)
• 129038 - AIS Class A Position Report (now usable)
• 129283 - Cross Track Error (one field left to explain)
• 129794 - AIS Class A Static and Voyage Related Data (now usable, ETA still wrong)
• 130836 - Simnet: Configure? (understands EP65R configuration data)

First version of a NMEA 2000 packetlogger

Shown at right is the NMEA 2000 network that I have assembled together so far. It's not complete yet, but it is enough to keep me busy for a while. Please note the large metallic object used as a base for the magnetic VHF antenna, also known as the Commodore PET 3032 computer that I learnt to program on way back in 1979. Those four IS20 displays in front of it are all more powerful than that machine with its 32 kbyte RAM and 1 megahertz clock cycle!

Over the past few weeks I've started a subproject where I am trying to see if I can read NMEA 2000 data flowing across the N2K network. This with the intention to create an integrated viewer that can show all data, including the environmental data generated by the sensors.

It turns out that just logging is not very hard. Logging and interpreting the NMEA data is a little harder. I've cross-checked with all sources that I could find across the internet. At the moment my logger app will log something like this:

# Timestamp Prio Src Dst Message

2009-06-02Z18:17:28,128 6 35 255 Distance Log: Log = 0 Trip Log = 0

2009-06-02Z18:17:28,128 2 1 255 Rate of Turn: Rate = 0.06443

2009-06-02Z18:17:28,128 6 0 255 Simnet: 65420: A = -2.477e+004 B = 6.365e+004 C = 3 D = 1

2009-06-02Z18:17:28,128 6 0 255 Distance Log: Log = 0.005 Trip Log = 0

2009-06-02Z18:17:28,128 2 2 255 Position, Rapid Update: Latitude = 52:01.***'N Longitude = 05:09.***'E

2009-06-02Z18:17:28,159 2 1 255 Rate of Turn: Rate = -0.03988

2009-06-02Z18:17:28,159 2 9 255 Wind Data: Wind Speed = 0m/s Wind Angle = 126.2degrees Reference = 2

2009-06-02Z18:17:28,175 2 1 255 Vessel Heading: Heading = 195.8 Reference = 5

2009-06-02Z18:17:28,175 2 0 255 Wind Data: Wind Speed = 0m/s Wind Angle = 33.48degrees Reference = 3

2009-06-02Z18:17:28,191 2 2 255 COG & SOG, Rapid Update: SID = 0 COG Reference = 0 COG = 219 SOG = 0.1166

2009-06-02Z18:17:28,191 3 2 255 GNSS Position Data: SID = 0 Date = 2009.06.02 Time = 18:17:28.00000 Latitude = 52:01.***'N Longitude = 05:09.***'

E Altitude = 8 Type = 3 Method = 1 Integrity = 0 Number of SVs = 9 HDOP = 1.1 PDOP = 2 Geoidal Separation = 47.1

2009-06-02Z18:17:28,191 3 4 255 Cross Track Error: A = 161.3 XTE = -0.01m

2009-06-02Z18:17:28,191 6 2 255 GNSS DOPs: SID = 0 Op Mode = 2 HDOP = 1.1 VDOP = 1.7

2009-06-02Z18:17:28,191 5 3 255 Environmental Parameters: SID = 242 Water Temperature = 26.73C ( 80.1F)

2009-06-02Z18:17:28,237 2 2 255 Position, Rapid Update: Latitude = 52:01.***'N Longitude = 05:09.***'E

2009-06-02Z18:17:28,253 2 9 255 Wind Data: Wind Speed = 0m/s Wind Angle = 124.9degrees Reference = 2

2009-06-02Z18:17:28,284 3 2 255 System Time: SID = 0 Source = 00 = GPS Date = 2009.06.02 Time = 18:17:28.00000

2009-06-02Z18:17:28,300 2 1 255 Rate of Turn: Rate = -0.03988

2009-06-02Z18:17:28,331 2 1 255 Vessel Heading: Heading = 195.8 Reference = 5

2009-06-02Z18:17:28,347 3 3 255 Water Depth: Offset = 32.77

2009-06-02Z18:17:28,347 2 2 255 Position, Rapid Update: Latitude = 52:01.***'N Longitude = 05:09.***'E

2009-06-02Z18:17:28,347 6 2 255 GNSS Sats in View: SID = 0 Mode = 2 Sats in View = 9 Sat # = 12 Elevation = 87 Azimuth = 7.998 SNR = 30dB Range r

esiduals = 0 Status = 4 Sat # = 30 Elevation = 53 Azimuth = -115.5 SNR = 23dB Range residuals = 0 Status = 4 Sat # = 9 Elevation = 46 Azimuth = 131

SNR = 39dB Range residuals = 0 Status = 4 Sat # = 14 Elevation = 44.99 Azimuth = -91.5 SNR = 29dB Range residuals = 0 Status = 4 Sat # = 27 Elevatio

n = 29.99 Azimuth = 130 SNR = 34 Range residuals = 0 Status = 4 Sat # = 4 Elevation = 19 Azimuth = 70 SNR = 26dB Range residuals = 0 Status = 4 Sat

# = 2 Elevation = 17 Azimuth = 108 SNR = 24dB Range residuals = 0 Status = 4 Sat # = 26 Elevation = 16 Azimuth = 183 SNR = 22dB Range residuals = 0

Status = 4 Sat # = 29 Elevation = 12 Azimuth = -176.5 SNR = 30dB Range residuals = 0 Status = 4

I'm already pretty good at decoding most common packets as seen on my network. For instance I've completely got the GPS messages down, and most of the sensor data. I'm not as successful yet with AIS messages, mainly because I'm short on AIS data where I am -- not a lot of ships in sight here! Also note the proprietary Simnet message in the log above, where I am just guessing at the fields for now.

Tying it all together - Overview

{Updated: June 16, 2009}

Enough has been done now to show what the entire electrical and navigation system on Merrimac II is going to look like. The goal was to have a system that's easy to use but not clutter up the entire boat with displays at various places. Not that you'd guess this from the image shown here at right -- you'd better click on it to get a readable image if you want to see it in more detail!

The cabin/saloon will not have any displays, buttons or nav systems except for a radio and a TV (hidden in a cabinet) and a charging cradle for the iPod touch remote.

The doghouse will have a PC display and a chartplotter and nothing else; all complexity will be operable from the PC and the remote (iPod Touch).

Power

Let's start from basics: power supply. The electrons are going to come aboard as follows:

1. Solar panels. 6 x Sunware SPR-90. 90Wp per panel. These should keep her happy while we're not there -- and even for a large part when are! I estimate that they can supply up to 2 kWh per day.
2. High power Mastervolt 24V/75A alternator on the engine coupled with an Alpha charge regulator. I've purposely decided on this model, as it charges at higher amps when the engine is running slowly than it's larger brethren.
3. A Mastervolt Chargemaster 24V/30A charger.

This will be sunk into 6 x 225 Ah Mastervolt AGM batteries, connected as 3 x 2 to provide 24 V @ 675 Ah. This means we can use about 330 Ah == 8 kWh before we need to top up.

On the consumer side we'll have a Mastervolt DC/AC converter that generates 230V, and a DC/DC converter that provides 12V for the electronics. There will be no AC-AC path from the shore connection to anything on board. In this way we don't need a isolation transformer.

The AC side is used by the following:

1. Hydraulic power pump for the lifting keel.
2. Washing machine (Miele, with hot fill capability so it can use warm engine water.)
3. Dishwasher.
4. TV.

The 12 V bits are used for anything electronic that needs/wants this. This keeps the supply clean, even when we use heavy electrical engines like the anchor winch. All motors etc are to be kept off this circuit, obviously.

The 24 V bits are for everything else: lighting, fridge, freezer, winches, autopilot.

Network

The electronics are going to be running on three networks:

1. Ethernet
2. NMEA 2000
3. Masterbus

The Ethernet will interface the Wago Linux PLC, the "integrator" Linux computer that provides WiFi and cellular access, a navigation computer running Microsoft Windows, a HDS8 chartplotter and a Broadband Radar radome.

The NMEA 2000 data will carry all navigation data. The components on this network are: Simrad IS20 instruments, autopilot and AIS class B transceiver; Lowrance HDS8 chartplotter/fishfinder/radar.

The Masterbus will couple all Mastervolt chargers/converters to each other. It integrates to the Microsoft Windows PC using a Mastervolt USB interface and possibly to the Linux system usign a Modbus interface.

What's not yet entirely clear is what will be used to tie the NMEA 2000 and Masterbus to the PCs, and what the PCs will be like. I'm investigating whether I can interface to these buses using my own software and off the shelf or custom CAN bus interfaces, as both of them are actually CAN. The fallback scenario is to use a Simrad AT10 interface for the Nobeltec software, a CANUSB for snooping the NMEA 2000 data and a Mastervolt Modbus interface for snooping the Mastervolt data.

For the Linux PC I'm contemplating various systems, but at the moment it looks as if I might as well use two (almost) identical systems such as the fit-PC2 for both the "always on" server and the Windows navigation system. An alternative is to make the server something that is ARM or MIPS based, as that should use less power. Sourcing an ARM based computer that is frugal with power (e.g. 2-3 W in total), has Ethernet, Wireless and USB or even better CAN directly on board turns out to be harder than I thought. There are a good many suppliers, but most systems fail on either being able to support an uptodate Linux BSP, or have the wrong peripherals, or are very expensive, or have a lifetime that is too short. If that is the case I might just as well use an expendable x86 computer that has plenty of USB ports and low power.

Navigation data

There will be four displays in the cockpit: IS20 Wind, Graphic, Multi and an AP24 pilot control. This gives ample data at disposal. There will be two depth sensors: one on the hull and one at the bottom of the keel. This is not just for redundancy, but also to keep from having to perform mental arithmetic as the keel depth can be varied from 0,80 m (2.6 ft) to 3,15 m (10 ft). This is important as our home waters are very shallow. The sensors work at different frequencies so they should not interfere with each other. The HDS can switch its depth sensor off when it's not needed.

The doghouse will have two screens: a Lowrance HDS8 chartplotter that also shows depth-over-time (aka a Fishfinder) and Radar. Next to that will be a computer display running Nobeltec Admiral and various other software. It will also run MSCAN Meteo (for receiving weather and NAVTEX data) connected to an ICOM PCR1500 remote controlled SSB receiver. The doghouse will also contain a Simrad RS82 VHF as well as an ICOM portable VHF and a Simrad WR20 remote. The remote allows you to control all Simrad equipment remotely as well as use it as a Bluetooth "headset" for a cellphone.

Simrad/Lowrance NMEA2000 network power usage

Third in what is turning out to be a small series on power usage. This time I figured I'd benchmark the power usage of all the navigation equipment that I have collected so far for the new boat.

Again measured using a Voltcraft 3000 at the 230V AC, so the actual figures are too high by 10-20% when using a direct 12V DC source. Since I am going to use a 24 V to 12 V DC/DC converter that will probably have the same sort of efficiency as the AC/DC converter that I am using now, I figure these measurements are good enough for me personally.

Device	Power	Cumulative
Lowrance HDS-8 (backlight @ 6)	6.3W	6.3W
Simrad IS20 Wind wand	0.9W	7.2W
Airmar DST800 depth/speed/temp sensor	1.0W	8.3W
Lowrance EP-65R fluid level sensor	0.4W	8.7W
Navico NAIS-300 AIS-B (receive mode)	7.3W	16.0W
Simrad RC42 compass	0.9W	16.9W
Simrad IS20 Graphic display	0.8W	17.7W
Simrad IS20 Multi display	0.6W	18.3W
Simrad IS20 Wind display	1.0W	19.3W
Simrad AC42 course computer	2.5W	21.8W
Simrad AP24 auto pilot controller	0.8W	22.6W
Airmar P319 sonar (depth) sensor	1.4W	24.0W

As always there are some small surprises here:

1. The chartplotter only uses 25% of the power envelope
2. NMEA2000 nodes seem to use at least 0.4W.
3. The NAIS-300 uses more power than I'd thought it would. Being able to shut it down completely is something to be considered.

Note to self (and reader): this is on the benchtop, the following is still missing:

• RF300 rudder feedback (should be neglible)
• Hydraulic pump (e.g. using the autopilot as opposed to just having it in standby)
• VHF #1
• Simrad WR20 remote
• Broadband RADAR sensor
• Ethernet switch

Lowrance HDS 8 power usage

Finally had a chance to hook up parts of the new NMEA 2000 kit to the power meter.

Running standalone (with no external sensors) the new Lowrance HDS 8 uses the following amount of power:

Standby ('off')	0.4 W
Booting (display 100% backlight)	14 W
Standby	5.0 W
Chart display (brightness = 1, backlight off)	5.0 W
brightness = 2	5.0 W (usable at night)
brightness = 3	5.1 W
brightness = 5	5.7 W (usable in cloudy day)
brightness = 8	8.9 W
brightness = 10	13.3 W (max, very bright even in sun)

Enabling the sonar added 2 to 3 Watt. In fact the sensor usage is the only difference between Standby and running with the backlight very low or off.

This was all measured at the wall plug using a laptop AC to 12 V DC converter and a Voltcraft Energy Check 3000. Actual power use measured at the DC input should be about 15% lower still.

All in all I am extremely satisfied with this new plotter -- Excellent functionality, great NMEA 2000 interfacing, great screen, cheap charts, all for a very reasonable price. I got mine from JG Tech in the UK.