28 June 2009

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:
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.

21 June 2009

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.

07 June 2009

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)

02 June 2009

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.

DC (and AC) power control

Our new sailing boat is proving to be a new playground for exercising some skills that I haven't used for 25 odd years. In particular, designing the DC and navigation systems that are going on board. I have slowly been coming up with what I think is a good mix of reliability, ease of use and high tech. This last bit just for the fun of it. But, let me start at the beginning...

We really like sailing, and sailing should be simple and fun. To make that come true you need to be comfortable as well. Over here in Northern Europe this means that during the colder months of the year you want heating on board. That and shelter from the rain. After some to-and-fro we decided to heat the boat using an ultra-reliable diesel-fired Kabola stove that is going to distribute the heat using hot water. As space is at a premium and we didn't like to have normal radiators in sight, we decided to go for floor heating. There is a Dutch company called Yacht Floor Heating that has come up with a solution that 'works' for yachts.

Floor heating does have the disadvantage that it takes a long time to heat up the interior initially, so we really needed a method of being able to switch the heating on remotely before we get to the boat in winter. Once you can remotely switch on the heat the question soon came up why the system should be limited to just that. Why not be able to do more, like monitor bilge water, battery charges and switch on fridges, deck lights? Why can't I check what the wind conditions are remotely? Maybe even put a camera on board?

Looking at the various options it soon was apparent that there are many systems on the market, but not one that integrated everything that I wanted from such a system.

What I wanted is something that:
  1. Does not interfere with manual operation. If the fancy electronics fail, the system should still be operable by hand. This rules out all new technologies that do distributed DC switching, as they rely on the electronic DC bus to be able to switch stuff on and off.
  2. Should offer a simple switches-and-lights interface that is easy to understand for people that are not comfortable with computers.
  3. Allows integration with modern technologies such as remote controls (locally and remotely) and Google Maps mash-ups.
  4. Can be replaced, extended and modified over time.
The DC wiring and all consumers are going to be installed by the builder. They pointed out that the relatively low complexity of the boat in terms of electrical consumers meant that a distributed DC layout was not going to provide many advantages, if at all. A single cabinet that is centrally located will suffice. This will also simplify fault detection and maintenance: all circuit breakers are located in the same spot.

The system that I have come up with is as follows:
  • The distribution cabinet will contain circuit breakers and old fashioned mechanical latching relays. As they are latching they don't use power in use. It also gives the opportunity to have multiple switches that toggle the relay state.
  • The switches can be located anywhere in the boat. They are momentary action switches coupled with a feedback LED. We've chosen to centralize them in a single board near the entrance, hidden behind a frosted glass panel.
  • A small Linux driven PLC contains digital I/Os as well as analog inputs. It can toggle the relays and measure their state. The analog inputs are used to measure all tank levels and possibly bilge levels. The WAGO PLC is modular and extendable but proven technology.
  • A 2nd computer will provide on-board WiFi and a cellular link to the Internet. This can be extended to a satellite link later on. This computer will also have a CAN bus interface so that it can talk with the NMEA 2000 bus that all the navigation systems are connected to. Finally it will also talk directly to the Mastervolt DC and AC power systems.
  • Local control is via an interactive AJAX driven website that is accessible, for instance, via an iPod touch or iPhone over WiFi, as well as any other computer that is onboard -- including the navigation computer.
  • Remote control is via any computer or phone connected to the internet. The actual connection will be via a proxy located in a data-center, as the cellular end of the boat does not have a fixed IP address. Access to the data will be using a form of authorization, of course.
I've started some prototypes for all this, and it seems that this will come together nicely. I'm working on a NMEA 2000 packet sniffer as well as a web application for the iPhone/iPod touch. You can see the "Fluid and battery level" screen of the app in action at the top of this entry.