Yacht Electronics

Packetlogger documentation: nmea0183-serial and iptee

2011-11-28T11:58:00.001+01:00

Although I love NMEA 2000 there is a role for (some) continued NMEA 0183 use. Since last week I run a Digital Yacht AIS receiver at home and upload the resulting AIS data to the internet. I'm station 727 at Marine Traffic and I also contribute the data to AISHUB.

This is where nmea0183-serial and iptee come in. These are new Linux and OS X programs available at my website as part of the packetlogger download (hey, maybe I should rename that!)

The nmea0183-serial program reads data from a serial port at 38,400 baud and sends it to stdout. The iptee program reads lines from stdin and sends it to any number of TCP or UDP servers. To make sure it does not block one service when another is unavailable it drops messages when a service is not available.

I use this as follows:

nmea0183-serial -r /dev/ttyUSB0 | 
   iptee -u data.aishub.net 2112 -u 195.251.168.18 5321 |
   tee /volume1/ais/ais.log

In the above example I feed the data to AIShub.net and Marine traffic via two UDP channels, and I log the data on disk as well. For display reasons the code was split over multiple lines; it was originally a single line.

Packetlogger documentation: n2kd - producing a json server for a webpage

2011-11-28T11:35:00.001+01:00

As you may have guessed from the -json option to the analyzer, I use it myself to produce data that is consumed by a webpage.

The webpage reads the data using AJAX and XmlHttpRequest. But for that to work nicely it needs a server that produces JSON, and that JSON should be as short as possible with each PGN only produced once. In other words, a webpage that is updated every 2 seconds does not want to know about the 19 rudder angle changes that were sent on the CAN bus in the mean time, only about the last one (or even better, the average -- but that is something my code doesn't do yet). Furthermore, if it is interested in AIS messages it wants to know about all AIS messages, not just the ones produced in the last two seconds.

So that's where a new program comes in, called n2kd (for NMEA 2000 deamon). It is available for Linux and OS X. This isn't very configurable yet, but I also don't know if anyone is interested. It is what I am using on-board at the moment and can be improved considerably. Let me know if you think this is useful if only it had such-and-such feature and I will consider it!

Here's the actual command that I use on board:


actisense-serial -r $ACTISENSE_PRIMARY | 
  analyzer -clocksrc 35 -json |
  n2kd

As you can see my GPS has CAN bus ID 35, so I give that to the analyzer to correct the computer's clock based on the GPS data.

The N2KD program is then contacted on port 597, and it will wait for 2 seconds and then spit out a full JSON structure containing all knowledge it has over all PGNs.

Note that this program will intentionally crash when it has no further input. I'm using a watchdog to restart the above command string when something goes wrong. It should probably just quit instead, but that's for next time.

Packetlogger documentation: the analyzer program

2011-11-28T11:04:00.001+01:00

The analyzer program contains the 'secret sauce'. It uses a database of PGN contents that has been painstakingly reverse engineered from observation of my network. I have not seen, read or otherwise obtained any material that I was not allowed to redistribute.Again this utility is very simple. It consumes the 'raw' ASCII PGNs produced by the reader utilities on stdin, and writes out the parsed PGNs. In a second mode it can also produce a human or computer readable form of the PGN database that it contains.So if you have saved the output of the reader in a file, you can analyze the data at a later data like this:


analyzer < your-actisense-output.log

For instance if we do that for the following output:


2011-11-24-22:42:04.388,2,127251,36,255,8,7d,0b,7d,02,00,ff,ff,ff
2011-11-24-22:42:04.390,2,127250,36,255,8,00,5a,7c,00,00,00,00,fd
2011-11-24-22:42:04.437,2,130306,36,255,8,b1,5c,00,ee,f0,fa,ff,ff

and use the above command to analyze this we get:


N2K packet analyzer $Rev: 233 $ from $Date: 2011-11-27 22:21:08 +0100 (zo, 27 nov 2011) $
(C) 2009-2011 Keversoft B.V., Harlingen, The Netherlands
http://yachtelectronics.blogspot.com

New PGN 127251 for device 36 (heap 5452 bytes)
2011-11-24-22:42:04.388 2  36 255 127251 Rate of Turn:  SID = 125; Rate = 0.0934 deg/s
New PGN 127250 for device 36 (heap 5467 bytes)
2011-11-24-22:42:04.390 2  36 255 127250 Vessel Heading:  SID = 0; Heading = 182.4 deg; Deviation = 0.0 deg; Variation = 0.0 deg; Reference = Magnetic
New PGN 130306 for device 36 (heap 5480 bytes)
2011-11-24-22:42:04.437 2  36 255 130306 Wind Data:  SID = 177; Wind Speed = 0.92 m/s; Wind Angle = 353.4 deg; Reference = Apparent

Now this output is readable for humans, but not very good for computers to parse and process further. If you want to use the analyzer in your software you're better of using the -json option which will produce lines like this:


{"timestamp":"2011-11-24-22:42:04.388","prio":"2","src":"36","dst":"255","pgn":"127251","description":"Rate of Turn","fields":{"SID":"125","Rate":"0.0934"}}
{"timestamp":"2011-11-24-22:42:04.390","prio":"2","src":"36","dst":"255","pgn":"127250","description":"Vessel Heading","fields":{"SID":"0","Heading":"182.4","Deviation":"0.0","Variation":"0.0","Reference":"Magnetic"}}
{"timestamp":"2011-11-24-22:42:04.437","prio":"2","src":"36","dst":"255","pgn":"130306","description":"Wind Data","fields":{"SID":"177","Wind Speed":"0.92","Wind Angle":"353.4","Reference":"Apparent"}}

The analyzer's second mode of producing the database that is kept within it can be accessed with the -explain and -explain-xml arguments. Further arguments are used when you are analyzing a particular PGN or a particular device.

Argument	Purpose
-raw	Show the raw bytes of the message data following the parsed data
-debug	Shows internal values of the parser; probably not readable for anyone but me.
-geo {dd\|dm\|dms}	Choose which format is used to print geographical locations.
-json	Format the output as JSON computer readable data.
-src <src>	Ignore input coming from other sources than the specified one.
<pgn>	Ignore PGNs other than this one.
-clocksrc <src>	Set the computer's clock with data from this source.
-explain	Produce the human readable list of PGNs that the parser understands.
-explain-xml	Produce the computer readable list, in XML format, of PGNs that the parser understands.

The -clocksrc argument is only supported on Linux and OS X.There is a -data argument, but that is not complete yet and will crash the analyzer.

Packetlogger documentation: ASCII raw format explained

2011-11-28T10:42:00.001+01:00

In this post we'll go into the format produced by the reader programs and consumed by the analyzer program. Here's a typical example of some typical PGNs that have 8 bytes of data:

2011-11-24-22:42:04.388,2,127251,36,255,8,7d,0b,7d,02,00,ff,ff,ff
2011-11-24-22:42:04.390,2,127250,36,255,8,00,5a,7c,00,00,00,00,fd
2011-11-24-22:42:04.437,2,130306,36,255,8,b1,5c,00,ee,f0,fa,ff,ff
2011-11-24-22:42:04.490,2,127251,36,255,8,7e,0b,7d,02,00,ff,ff,ff
2011-11-24-22:42:04.493,2,127250,36,255,8,01,5a,7c,00,00,00,00,fd

8 bytes is the usual amount because that can be transmitted in a single CAN message. Longer messages are transmitted in multiple CAN messages. The reader programs 'solve' this and only send out coalesced complete PGN messages, for example:

2011-11-24-22:41:10.034,6,129540,36,255,123,24,ff,0a,03,68,03,a2,0d,00,00,ff,ff,ff,7f,f1,05,44,2a,c2,9a,04,10,ff,ff,ff,7f,f2,07,dc,17,e7,28,04,10,ff,ff,ff,7f,f2,08,0a,2f,0a,2f,e4,0c,ff,ff,ff,7f,f2,0a,f4,0c,c3,6d,68,10,ff,ff,ff,7f,f2,0f,f4,0c,9e,c1,10,0e,ff,ff,ff,7f,f2,13,68,03,16,22,00,00,ff,ff,ff,7f,f1,15,7f,07,ef,de,48,0d,ff,ff,ff,7f,f2,1a,dc,26,fb,c2,a0,0f,ff,ff,ff,7f,f2,1c,2e,17,2c,62,10,0e,ff,ff,ff,7f,f2

So what is this format?

The format is a very strict and simple ASCII representation of the binary CAN data. It contains the data in a format that is easy to parse by further programs. It is also still somewhat readable, unlike the CAN binary messages.
It contains one PGN per line, and consists of a fixed set of 6 fields that are always the same, followed by a variable number of data fields. The first fields are:

Number	Field
1	Timestamp when the message was received
2	Priority of the message
3	PRN, the identifier that explains what type of message it is
4	Source ID of the device that produced the message
5	Destination ID, 255 means broadcast
6	Number of data bytes to follow
7 ... n	Data bytes in hexadecimal format

Packetlogger Documentation: Getting data out of your Actisense NGT-1

2011-11-28T09:57:00.001+01:00

The programs that I make available are all command line utilities. Normal for UNIX folks, somewhat exotic for OS X folks and downright frightening for Microsoft Windows users. Or maybe the other way around. Anyway, I don't have the time to develop GUI programs.

If you are not used to command line tools, and don't fancy learning them these programs are not for you.

So the first thing you need to do is open up a terminal or console. Or for those still used to that terminology, open up a DOS box. It hasn't been a DOS box for ten years, but that's what my sailing friends still call this. Click Start -> Run then type cmd.exe<enter> to get a console.

On Microsoft Windows you'll use the program actisense-reader.exe. First run it without any arguments. It will show you a list of COM ports. One of them should be your Actisense NGT-1 NMEA 2000 gateway, and it should say "Available" as well.

For instance:


C:\packetlogger\windows-x86>actisense-reader.exe
actisenser-reader $Rev: 235 $ $Date: 2011-11-28 09:23:14 +0100 (ma, 28 nov 2011) $
(C) 2009-2011 Keversoft, Harlingen, The Netherlands.

Usage: actisense-reader.exe <com-port> [<baud-rate>]

<com-port> is an integer from the following list:
1: COM1 - Communications Port (Available)
2: COM2 - Communications Port (Available)
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)

This program reads from the indicated COM port until input on stdin is received. Normally this means until you press the 'Enter' key on the keyboard.

Once you have found the appropriate free NGT com port you can start the program again and pass it the number of the COM port, for instance:

C:\packetlogger\windows-x86>actisense-reader.exe 3

If your NGT-1 is connected to a network you'll see the program start emitting ASCII data, one line per NMEA 2000 PGN:


2011-11-24-22:42:04.388,2,127251,36,255,8,7d,0b,7d,02,00,ff,ff,ff
2011-11-24-22:42:04.390,2,127250,36,255,8,00,5a,7c,00,00,00,00,fd
2011-11-24-22:42:04.437,2,130306,36,255,8,b1,5c,00,ee,f0,fa,ff,ff
2011-11-24-22:42:04.490,2,127251,36,255,8,7e,0b,7d,02,00,ff,ff,ff
2011-11-24-22:42:04.493,2,127250,36,255,8,01,5a,7c,00,00,00,00,fd

On Linux and OS X the program to use is called actisense-serial, and it needs a device name. You'll have to dig around in your OS console logs (OS X: console.app, Linux: dmesg) to see how your NGT-1 has been recognized by the operating system. Let's assume it is /dev/ttyUSB0, in that case you use


actisense-serial -r /dev/ttyUSB0

Why the -r? Well, this program can also write PGNs to the bus using the same ASCII protocol as it uses to receive PGNs. This means that if you have, for instance, two NMEA2000 networks and you want messages to be passed from network A to B -- in other words read from A and write to B you do this like this:


actisense-serial -r /dev/networkA | actisense-serial -w /dev/networkB

Or if you want to read PGNs from A, inject those into B and then view the output from both networks you do this like this:


actisense-serial -r /dev/networkA | actisense-serial /dev/networkB | ....

If you do not want to inject the messages from A into network B, but you do want to view the output from both networks you use the 'pass thru' option:


actisense-serial -r /dev/networkA | actisense-serial -p /dev/networkB | ....

In a next blog post I'll show you what the output format generated by these programs contains and what you can do with the output.

Packetlogger Late 2011 edition

2011-11-28T09:47:00.001+01:00

This blog has been pretty quiet over the last few months, but now I've finally found some time to update the public version of my NMEA 2000 reverse engineering research and NMEA utility programs.In the last year I have had the chance to observe my personal network and fix a large number of small bugs in the definitions. It now looks as if my programs and database are able to decode all common NMEA 2000 messages and a number of the proprietary ones that occur on my own network.This means that the following messages are all in order:

Basic NMEA 2000 (ISO request, claim, acknowledgement etc.)
Basic sensor data (wind, depth, heading, GPS, rudder)
Some electrical sensor data (switch status, battery, inverter, …)
Normal AIS messages (class A, class B)
The 'basic' route message

What I have not tested are things such as:

AIS uncommon messages such as SAR
Engine parameters, transmission parameters, trip parameters
DSC call information
Most route and WP service messages

This does not mean that these messages aren't in the database or that they are incorrect -- just that I don't know exactly how well they match up. For these 'incomplete' messages your help is appreciated. In my next post I'll tell you how you can do this.Also I'll be publishing some documentation posts on how to use the programs.To download the programs please go to the packet logger page on www.keversoft.com.

iNavX on the iPad

2011-06-22T22:06:00.003+02:00

I thought I'd share my experience with iNavX on iOS with you.

As most boaters with an iOS device I was quick to download the original Navionics programs. Although hefty downloads they work quite well. Scrolling and zooming is pretty smooth in the Navionics apps. They are a little unstable requiring an app restart now and then, but not very often.

When I learned that iNavX supported a TCP feed I rewired my AIS transceiver into my Linux box and had that start sending AIS and GPS data over TCP, and bought a license for iNavX and a set of (Navionics) charts. This works great, and I'm now able to see my navigation data and AIS targets on my iPad. This promotes the iPad from a good tool for situational awareness to a great one.

There are still a few issues that you should be aware of in case you're considering to use your iPad for full navigation duty, with any app. Depending on your use you may need a waterproof case and have a problem with sun viewability. Also, although iOS supports multi-tasking, it's too easy to accidentally stop an app. In general the large amount of memory that the navigation apps seem to use also makes for occasional crashes. Thus, keeping these apps running for hours on end is not how I personally see them at their best.

Also there is a bit of a downside to the way that iNavX works with charts. Although it is beautiful that you can buy charts online and then download these to the device, it looks as if the charts are stored as "disposable documents." When I upgraded my iPad from 4.3 to 4.3.3 I lost all my charts and had to download them again. As that didn't work at sea without internet I had to fall back to Navionics for a while. Next time I'll make sure I test my chart store after updating the device.

L&S Ecopilot reduces autopilot current consumption

2011-06-02T08:26:00.005+02:00

I just installed an Ecopilot device made by Lecomble et Schmitt from France. Let me tell you what this does and how much of a difference it makes to our power consumption.

Our autopilot uses a reversible pump that sends hydraulic fluid backwards and forwards through a rather stout cylinder. It has ample power to steer the boat, much more than I have certainly!

For those times when you do not want to steer by autopilot, or when it is off, a bypass is installed. Look at the photo on the right. The steering cylinder is at the very bottom of the picture. The black and black-and-orange hoses carry the hydraulic fluid from the pump (not depicted) to the cylinder. The bypass line is the shiny "inverse U" shaped pipe. At the rear you see a metal box with a plastic black blob attached to it with another smaller blob attached to it and a black cable sticking out. The metal box contains a hydraulic valve that is controlled by a solenoid (electromagnetic coil) in the bigger black box. Industry has, smartly, standardized the size of these solenoids and even the connectors.

The story of today is about replacing the smallest of the two black boxes. This is a replacement for the standard connector that attaches to the industry standard magnet. As you can see here it isn't much to look at. Instead of the normal connector which only contains a bit of plastic and some screws, this version contains a small electronic circuit that aims to reduce the power used by the magnet. The reasoning behind this product is that the current used by the solenoid to move the valve initially is much higher than the current required to keep the valve open. Since the standard coil is just a bit of wire it doesn't know how to do this. And that's where the Ecopilot comes in: it measures the current and reduces this to the point where the valve just stays open.

With my solenoid the power consumption went from 1.4 A @ 24 V to 0.3 A. That is a 1.1 A saving, and adds up to a 26,4 Ah savings per day (when sailing). So this € 110 device is a very worthwhile investment -- easily cheaper than adding another solar panel.

To find one on sale, search the internet for "ecopilot 2204028" for the 24V version and "ecopilot 2204027" for the 12V version. Note that most web stores selling this will be French. The one that I ordered from (www.tyboat.com) was very helpful but their online ordering process did not yet take into account any increase in shipping costs outside France... C'est la vie.

Solar cells

2011-05-27T09:21:00.008+02:00

One of the decisions that we made early on when building our new boat was to have an array of solar cells on a spoiler at the rear. Well, I wanted them and had to convince the admiral, but anyway. The reason to choose for PV (Photo Voltaic) solar cells is that they work without needing any supervision when you are away from the boat, maintenance is limited to an irregular cleaning interval and most importantly on a sailboat, that they do not make any noise.

What we definitely did not want was flexible panels on top of the pilot house or deck. Not only are the flexible panels a lot less efficient by themselves, having multiple entry points for the cables makes for leaks, and they also heat up because they cannot shed their heat radiating downwards. Hot solar panels work slower. This then is a bad compromise: the warmer the climate the more likely you are that you are going to have a nice overhead sun but your panels will not be putting out as much. Just at the time that your fridge is working overtime! So no flexible panels for us.

As boat #1 had a quite nice antenna and PV spoiler at the very rear of the boat, we opted for the same manner of construction. Although the spoiler can be considered ugly, it keeps out of the way, provides for a good way of lifting the rowing dinghy. It turns out that it's also a half-decent bimini, although for that purpose it could even be larger.

Technically we used the best panels we could find. I did not want the total panel area to be wider than the boat or stick out from the rear; this way you can safely enter a lock without fear of endangering the panels. On the front side the panels are limited by the backstay. This gave us an an area of about 3,30 by 1 m. This enabled us to fit 6 panels rated at 100 Wp.

Given that we're (still) in the NW of Europe at 52° N and that Wp is a theoretical maximum, I was told that a fixed setup (on land) of 600 Wp would bring in about 500 kWh per year. On the downside, our boat's panels are not angled, and there is some shadow from backstay and antennas. Fortunately the sun tends to shine more at sea or near the sea. So I figured 25 % loss, e.g. 375 kWh per year or a 1 kWh per day average. Since the sun shines a lot more in the summer, figure about 70% more during summer, which happily coincides with our summer holiday!

In practice

So how did this work out? Very well. Last year we never used any shore power whilst cruising, but did not yet keep a full tally. Last winter when we were on board and the Kabola heater was running full blast (outside -7 C) we obviously did use shore power. Solar cells were not doing much then when the sun is above the horizon only a little and only for maybe 8 hours!

Back to today, and here are some snapshots from my monitoring app from this week -- end of May. This means the sun officially rises at about 6:30 and goes down at 21:30. In the first image you can see the current at which the house battery is being charged or discharged. The at-rest usage this week is 1,7 A (monitoring stuff, all mastervolt equipment on, winches and hydraulics powered but the fridge is off.)

These images span a week running from Friday morning to Friday morning. On Saturday and sunday I was on board, using all sorts of stuff including running the inverter for watching TV and some chores. I also did some upgrades to the monitoring software, so you see a 'glitch' in the data where the graph is interrupted. From Monday onwards no-one was aboard, and you can see that on Monday the sun was out, as the effective current into the batteries reached a maximum of 13.4 A. Combined with the load that means the solar array was pumping out 15.1 A.

You can also see that on Wednesday the batteries were reaching a completely full charge.

So you can see that certainly they are doing what they were supposed to do: deliver us the boat on a full charge in summer.

Observing the electrical behaviour of a NMEA 2000 network

2011-05-23T22:38:00.000+02:00

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.

Airmar DT800, DST800 and PB200 disappearing from the NMEA 2000 bus

2011-05-23T21:52:00.001+02:00

Last year I had some issues on our own new boat with the NMEA 2000 network. Some devices, in particular the Airmar sensors, would suddenly drop off the bus as if they were no longer there. After about ten minutes or so they would magically reappear. Most often I would not be that patient and cycle the network power; this helped all the time, but was very annoying.

The problem happened a few times a day for the DST-200 depth/speed sensor and about once a day for the PB-200 multifunction sensor. I thought it was interesting that only the two Airmar devices had this issue whereas the 10+ Simrad/Lowrance/Mastervolt/Actisense devices on that same network had no such issues.

I can now report after 2 months of testing that this can be fixed by loading new firmware into the Airmar sensors. This can be done by downloading the Airmar Weathercaster software and then applying the firmware update through that. Note that this is the approved manner of doing this, even if you do not own a PB200 but only a depth/speed/temperature (DST800) or depth/temperature (DT800) sensor. I upgraded the DST800 to DST200_a1_1022 and the PB200 to PB200_a1_1611_a2_1611 after which the problems have been fixed. According to my friendly Simrad engineer, Airmar actually repaired the issue in software release 1021.

Link to the Airmar download page

Options for a wireless navigation display

2011-04-12T17:19:00.000+02:00

A few years ago I had the almost-perfect wireless display setup for accessing Microsoft Windows based navigation software.

It consisted of a fixed X86 computer running Microsoft Windows XP and a Panasonic CF VDW07, or Windy, as they were affectionately known. They were completely portable, IP54 or better rated, and were really useful for use outside. In the image at the right it's me using one at sea:

The Windy was really portable, made from magnesium, waterproof enough for outdoor use. On the not-so-good side, the display was somewhat difficult to read outdoors (I had the 'high brightness' version, as the transflective version was not longer available by the time I bought it.) It had a 800x600 display which was really the lowest resolution that is acceptable for a chart display, had the tendency to run down on the battery at inappropriate moments -- I soon learnt to recharge the battery before coming to a difficult part of a trip.

The worst part of it is that it uses its own software for creating the remote desktop, and that this software is not compatible with Microsoft Windows versions beyond Windows XP/2003.

So what alternatives are there? Surely five years later a better solution must exist?

Let's examine a few of those.

Remote Displays

The obvious successor of the Windy is the Panasonic CF08 which was released in 2007. It uses a slightly bigger screen (10.4"), has more ports (bad, more chance of water ingress), better resolution (XGA -- 1024 x 768) and uses Microsoft's Remote Display Protocol, making it compatible with any Windows version. This is even more expensive than the Windy was though, I think it was about $2000. It is no longer being made, as far as I know.

I tried other wireless displays such as those offered by Philips and Viewsonic, but the ones that I tested were not suited for marine usage. It does look as if these devices are fading from the manufacturers minds, with the market being too small.

Portable computer (tablet)

Instead of just remoting the display you could also use a wireless computer, i.e. a tablet. There are a number of rugged solutions such as the XPLORE iX104, but that again is quite expensive; the online prices that I found started above € 2000 but climbed rapidly to € 4000!

So how about one of those iPad style devices, but still running Microsoft Windows? The slates coming out in 2011 as alternatives to the iPad are much friendlier priced. A string of these have been announced at CES 2011, but none are available yet.

As our new boat has a doghouse where we can use the device the waterproof aspect has become a lot less important; we're using our iPad to good effect inside. Using it inside also solves the fact that LCD displays just aren't good enough outside, unless you power them with huge backlights or use transflective displays that ruin the color fidelity.

The "portable" aspect of these computers would allow occasional use outside in benign conditions, and being able to use them from the port bench when my daughter is asleep on the starboard one (which is where the current fixed computer screen is located.) What I don't know at this stage is how robust these Windows tablets are going to be, and whether they need ventilation. Since anything with vents will be ruined in a few days in a salt water environment, that would rule them out completely.

Remote USB devices

It used to be that using a completely wireless computer was not feasible since you needed USB or serial connections for the navigation data, but as the readers of this blog may now I've cracked the navigation data problem, and I also found a solution for remoting other USB devices, which is the Eltima USB over Ethernet software. This allows you to keep stuff like those pesky license dongles plugged in to a different computer.

Using an iPad or Android tablet

Since we've already got an iPad, why aren't we using this for the remote display? Good question! A tablet is pretty good at running apps like iNavX, AyeTides and my home-built remote control web application.

Unfortunately, the display is very hard to see in direct sunlight and the box is not water resistent, needing an extra (cumbersome) case.

Conclusions

Five years on, and still the ultimate navigation display doesn't exist -- unless you have a better solution? Let me know what you think!

Keeping an electronic library of on-board documentation

2011-03-10T17:28:00.000+01:00

One of the great uses for using a tablet is for reading documentation. I've currently got 7 binders full of documentation on board. Most, if not all, of that material is available online.
At the moment I've got 204 PDF manuals relevant to things that I use on board available on my iPad.

I am using Dropbox to accomplish that. If you haven't experienced Dropbox you are missing out. They have clients for Windows, Linux, OS X, Android and iOS, so it is more than likely that all your devices are covered. Once you install it on at least two of them it is super easy to sync files between your connected devices. The free service covers 2 GB, which is plenty for personal documents, and you get more if you refer others.

The way that Dropbox is works is that it uploads anything that you put into your personal dropbox folder to the cloud (Amazon S3, to be precise). That means your files are backed up as well! Your devices then sync to the cloud; this means there are no nasty firewalls to set up or anything like that, and that these files are "always available". Very cool...

If you are interested please click here to install it; this will give me an extra 250 MB of storage.

Chetco SeaSmart

2011-02-26T21:22:00.000+01:00

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.

SRT proprietary AIS commands

2011-02-25T11:19:00.001+01:00

My Navico NAIS-300, like most other commercial AIS class B products that have been available for a while, uses the SRT AIS class B OEM board. I know the same board is used in the Raymarine 500, True Heading AIS-CTRX, Transas, Digital Yacht AIT250/1000, and many more. The tell-tale seems to be that the AIS transponder comes with Pro AIS software. I have hooked up a serial data logger so that I could find out what NMEA-0183 commands the Pro AIS software sends to the transponder. Unfortunately neither SRT nor any of the vendors publish the protocol.

My research into this started because I wanted to control my AIS transponder's transmit setting using software. For some reason there are many functions that you can assign to the remote button input, but not a reliable level-style on/off of the transmit functionality. This has been added to recent firmware versions, but mine contains older firmware. However, an hour's worth of analysis shows that controlling the transmitter is actually quite easy. In fact, almost everything that you can set up using Pro AIS is easy as pie to implement.

Basics

The SRT product, logically, uses the 'P' prefix to indicate Proprietary, followed by SRT. Here is an example of a PSRT message:

$PSRT,LED,01*49

Just like all other sentences I document on this page the shown message format is inclusive of the NMEA style checksum bytes at the end of the line, e.g. *49 in the message above.

For some reason some sentences start with a prefix $DUAIQ. I have no theory as to why this is so, maybe the data is intercepted by a different microcontroller.

Authorization

Some sentences require the passing of a password. Luckily, the protocol to do this is very simple -- just send the following sentence before every authorized message:

$PSRT,012,,,(--QuaRk--)*4B

Silent mode

To make the AIS silent (not transmit its own position) send the following authorized (prefix with the command above) sentence:

$PSRT,TRG,02,33*6A

To make the AIS transmit its own position send the following authorized sentence:

$PSRT,TRG,02,00*6A

Alarm mode

To make the AIS output all alarms every minute send the following authorized sentence:

$PSRT,ALM,0000*45

To make the AIS output only the active alarms send the following authorized sentence:

$PSRT,ALM,0001*44

GPS update speed

To make the AIS output GPS data every second send the following authorized sentence:

$PSRT,GER,01*54

To make the AIS output GPS data every four seconds send the following authorized sentence:

$PSRT,GER,00*55

GPS data

The SRT board has a complete GPS on-board. For some reason it only sends out two GPS sentences: RMC and GBS. See the GPSD source for more information on these sentences (as well as those below.)

To get the GPS to send out more GPS sentences send the following authorized sentence:

$PSRT,GPSDATA,,,1*60

This will cause the board to send out VTG, GGA, GSV, GLL and ZDA sentences as well as RMC and GBS. My particular board has a small bug in that it also starts sending out two copies each of the RMC and the GBS commands.

To get it to stop sending the additional GPS messages, send the following authorized command:

$PSRT,GPSDATA,,,0*61

Interrogating the board

There is a whole stack of sentences that can be used to read out system information. These are

LED status

Send: $DUAIQ,LED*29
Recv: $PSRT,LED,a*hh
a bit 1: Power On
a bit 2: TX timeout
a bit 3: Error
a bit 4: SRM status
hh: checksum

Internal data

Send: $DUAIQ,ADC*22
Recv: $PSRT,ADC,a,b,c,d,e,f,g*hh
a: Tx forward power
b: Tx reverse power
c: RSSI Rx 1
d: RSSI Rx 2
e: Internal 3V3 supply
f: Internal 6V supply
g: Supply voltage
hh: Checksum

Boat data

Send: $DUAIQ,SSD*20
Recv: $AISSD,a,b,c,d,e,f,g,h*hh
a: Callsign, 8 bytes fixed length; @ for unused bytes
b: Ship's name,20 bytes fixed length; @ for unused bytes
c: GPS antenna distance from bow, in m
d: GPS antenna distance from stern, in m
e: GPS antenna distance from port side, in m
f: GPS antenna distance from SB side, in m
g: ?
h: ?
hh: Checksum

MMSI

Send: $DUAIQ,010*55
Recv: $PSRT,010,,,c*hh
a: ?
b: ?
c: MMSI

OEM name

Send: $DUAIQ,SRM*28
Recv: $PSRT,SRM,a,b,c*hh
a: ?
b: ?
c: OEM name used in AIS messages, 7 bytes fixed length; unused bytes are filled with @.
hh: Checksum

Vessel type

Send: $DUAIQ,VSD*25
Recv: $AIVSD,a,b,c,d,e,f,g,h*hh
a: vessel type. 36 = Sailing vessel, 37 = Pleasure craft
b: ?, always 00.0
c: ?, always 0000
d: ?, always @@@@@@@@@@@@@@@@@@@
e: ?, always 000000
f: ?, always 00
g: ?, always 00
h: ?, always 00
i: ?, always 00
hh: Checksum

Software version

Send: $DUAIQ,SWF*26
Recv: $PSRT,SWF,a,b*hh
a: AIS software version
b: FPGA version
hh: Checksum

Transponder Serial Number

Send: $DUAIQ,SNO*36
Recv: $PSRT,SNO,a*hh
a: Serial number in ASCII, 10 digits. Usually all 0.

Reset Data Programming

The following command can be used to reset the AIS back to its factory settings, inclusive of the MMSI number, so that it can be reprogrammed, for instance when you want to sell your AIS transceiver.

$PSRT,RDP*6F

I have received numerous reports from people who tell me that this works fine, over a range of devices. Just make sure your AIS came with ProAIS and you should be OK.

NMEA 2000 connector pinout - Smart!

2011-02-19T16:57:00.001+01:00

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

2011-02-17T17:27:00.001+01:00

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.

A simple forwarder for AIS and NMEA 0183 data over TCP/IP

2010-12-31T22:46:00.000+01:00

I've recently moved the NMEA 0183 HS serial port from my Windows PC input to the central Linux micro computer, and written a small script that retransmits the serial data out over TCP/IP.

This has a number of advantages in my particular install:

It allows me to log the AIS data stream.
It allows me to view the AIS on both Expedition and Nobeltec software at the same time.
It allows me to simultaneously access the AIS stream from my iPad. I've tested it with Digital Yacht's iAIS app, but it should work with other apps running on the iPad.

So instead of being able to use the AIS data only on a single Windows application I can now use it on all navigation hardware access that I have on the boat. Quite an achievement for moving one plug and writing a little bit of PHP code.

The code really is very simple - it reads an entire line from the serial, detects any new clients and then forwards it to all TCP clients that have connected to it. Then loop. As a bonus it will cache the last received 200 AIS messages and send those immediately to any client that connects. This in the hope that this contains a number of VDM type 5 and 24 messages so that the client can show static AIS data immediately.

You can download the nmea_to_tcp script here. I'm releasing this under the GPL v3.

To use this code you must have a computer that has a PHP5 CGI interpreter. On Microsoft Windows you may want to remove the first line of the nmea_to_tcp script, as this instructs a Linux system to use the PHP interpreter. You may need to install the DIO direct I/O package.

Connect you AIS receiver to a serial port, and then start the script with the name of that serial port as it's first argument, for instance nmea_to_tcp /dev/ttyUSB0 on Linux; it is probably something like nmea_to_tcp //./com1 on Microsoft Windows.

That's all. You should now be able to connect to the system at TCP port 2000.

Nobeltec and TCP streams

By the way, to get Nobeltec to use the TCP stream -- you can't rely on the built-in Glass bridge functionality. You have to convert the TCP stream back to serial data, for instance using the open source com0com and com2tcp software.

Are you unable to find the website for Expedition navigation software?

2010-12-31T22:07:00.000+01:00

I recently attempted to download an update to the awkwardly named but excellent Expedition navigation software written by Nick White. Apparently Nick was getting a little bored with running a website, as the former site at the original site www.iexpedition.org is no longer in existence. At the time I was redirected to the new distributor, Tasman Bay Navigation Systems.

Today I was looking up that new address for a different post I was making, and noticed that iexpedition.org is now no longer in function and has been clobbered by one of those domain squatters.

For that purpose I am writing this post in the hope that you may find the new site for Expedition software more easily at: Tasman Bay Navigation Software.

Collision on the North Sea

2010-12-26T00:00:00.000+01:00

A few days ago two cargo ships collided in the North Sea in the beginning or just before the TE Traffic Separation Scheme, the 395 m (1200 ft) long CMA CGM Laperouse and the 90 m (300 ft) Thebe, luckily with little damage. Conditions were not great, 3m swell with a 40 - 45 knot wind, but not completely atrocious either.

You can see where the accident happened on MarineTraffic's AIS log of the Laperouse's track.

Here is a scanned recording of the VHF transmissions of the the Dutch Coastguard and rescue services (from scannernet.nl).

Now both of these vessels are mandated to have AIS on board, but that doesn't say both had fully integrated AIS sets that would warn them about an upcoming collision. Even so, it's hard to understand why these accidents still happen even with all this tech aboard.

It shows that although AIS is a great help to all parties there is apparently still enough room for error such that a large(ish) cargo vessel is able to collide with one of the largest container vessels in the world.

BR24 software update

2010-10-13T16:11:00.001+02:00

I just noticed that Navico has released a small sofware update for the Navico BR24 radar.

Version 2.9.273 fixes a problem where guard zones may not trigger until the alarm type has been changed.

Packetlogger update with fixed field lengths and lookup values

2010-10-06T13:34:00.001+02:00

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.

Low power USB display

2010-09-28T20:49:00.001+02:00

I'm eagerly awaiting more news concerning the new USB version of Pixel Qi's outdoor viewable 10" LCD screen. At 1.5W at full power this sounds like the ideal solution that we have all been waiting for.

A German company named Display Solution AG is going to produce a combination of the well-known Displaylink USB video display technology combined with the aforementioned Pixel Qi display. I've tested Displaylink devices earlier, they are fast enough for a chart display and general 2D use. 3D or video is a bit of a challenge, but I don't think that's what most yachties are looking for.

Once this happens all that needs to happen is for someone to package this in a IP 67 case and we've got the perfect marine display!

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

2010-09-27T17:24:00.001+02:00

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;
    }
  }

}

CANBoat Design part III - Choosing the server hardware

2010-09-21T22:32:00.002+02:00

The server that CANBoat runs on was always designed to run 24 by 7. This means that it must be reliable and use little power. Power usage adds up over longer periods. Something that uses 3W will use 6 Ah @ 12 V per day. So every Watt counts!

For a long while I thought that I would end up with some form of embedded ARM board running Linux. I bought a number of ARM based systems to run field tests.

However as I started to develop software it soon turned out that the criteria list contained three items, not two:

Power usage - as low as possible IN REAL LIFE.
Connectivity - USB 2.0 Host, Ethernet, Wifi.
Up-to-date Linux kernel with distribution that provides lots of packages.

I was surprised to find that in practice a small x86 server based on the AMD Geode ran with almost as little power as an ARM board. Unlike the ARM boards it had all the I/O that I wanted. Furthermore it was cheap and reliable to procure. You can get cheap ARM boards based on commercial items such as routers but these usually have a very short lifetime as manufacturers continuously drive down prices by bringing out new hardware. Embedded systems are usually a lot more expensive.

The clincher was that most ARM board manufacturers have a hard time keeping up with the Linux distributions, so they usually run out-of-date kernels and weak distributions. Support for FTDI serial converters was not a given, and these are used in many devices such as the Actisense NGT-1. I had to backport many fixes for the FTDI serial converters to the older Linux kernels to get reliable serial USB connections. Not Good.

So in the end I decided on low power x86. The PC Engines ALIX 2d.13 has exactly the interfaces I needed, but is available in a range of different systems. They run about € 100 / $ 140 which is still very reasonable. It runs a very nice mini Debian release named Voyage Linux with a kernel that is new enough to run stuff like the FTDI interfaces reliably. As it is just a pruned Debian release getting an additional package is just an apt-get away. The processor is a 500 MHz AMD LX800 which is plenty fast for Linux server needs.

CANBoat Design Part II - why a website, and why TCP and JSON

2010-09-21T17:13:00.002+02:00

One of the first things that people ask me when I show them my app on the iPhone or iPad is where they can download it from in the App Store. My answer is simple: you can't. Nor do you need to. It would be bad design if you had to!

The idea is that all devices on board that have a decent web-browser can access the CANBoat data. This means I save development effort, as I don't need to write custom apps for Blackberry, Android, iPhone, Windows Mobile, etc. All I need to do is make sure the webpage renders nicely in modern browsers. I did make a decision that I'm not going to cater to Internet Explorer, not unless it is IE 9 that is.

The choice for a webserver hosted on a permanently running small (Linux) server and clients running a web browser has two other very big benefits.

First of all, since there is no need to install anything the client hardware becomes expendable. If you lose one (for instance it gets soaked) then you just get a new one. For use in the cockpit you'll still be using some protection, but that's true of your phone itself anyway. Yesteryear's iPod touch that your kids no longer want because it is 2 generations behind will serve as an excellent client. And it gives you an excuse to get a bigger screen -- as in an iPad which you suddenly have a "very good reason to buy" for.

Secondly, because all state is carried in the server you can switch off the client for as long as you like. When you start it again the page refreshes or you restart the 'web app', and all data is there as the server knows what the system state is. All logging etc. does NOT require a permanently running iPhone app. Even the anchor alarm (once I get around to implementing it) will work this way!

The webpages

The beauty of modern browsers is that they can accomplish a lot in just a little Javascript. For instance, the following gauges are all rendered client-side in a few hundred lines of Javascript code:

The above gauges are how clients that are connected via a slow link will see the page. If they are connected using Wifi the gauges are shown with a nice image that has reflection in it, upscaling the experience.

Also, the server side examines the browser capabilities so that the page is tuned to the capabilities of the device. At the moment I change the tab bar to a drop down list if I detect a small screen. Various Apple Webkit items are sent to make it possible to run the application without a page header on iOS devices.

Refreshing the on-screen data

As browsers are not capable of receiving UDP packets yet, they need to get their data in a different way. The only capability that they have is creating TCP connections to refresh their data. That technique is called AJAX (Asynchronous Javascript and XML), but instead of XML I use JSON format. JSON is ideal for Javascript as it is translated easily into real Javascript object data.

The JSON that would be sent for the above three dials is something like this:

[ 
  {"name":"Heading","units":"°","value":357.7},
  {"name":"Batt Voltage","units":"V","value":"27.06"},
  {"name":"NMEA Voltage","units":"V","value":"12.65"}
]

CANBoat Design part I - A simple data viewer and boat remote control

2010-09-21T16:51:00.001+02:00

Today I'd like to tell you a little more about the hardware/software stack that I have developed to control and navigate a small to medium pleasure boat. The basic idea is to re-use the mobile devices that most boaters will have, such as their smart phones, tablets, laptops or computers.0

If you've ever stumbled across Panbo then you may have realised that there are many folks that want open access to environmental and navigation data. There are plenty of mobile navigation software programs that show a chart, but there aren't so many that show instrument or actually sensor data on mobile devices.

My own boat has a PC running Nobeltec and, since recently, Expedition navigation software with CMap charts as well as a Lowrance HDS chartplotter with Lowrance and Navionics charts. I also have the Navionics Mobile charts on my iPhone. That means that charts are very well covered, thank you.

What I did not have was:

Remote control over heating. We have under floor heating, so switching this on a few hours before we actually leave for the boat is very welcome in winter.
A way to control the power circuits from other locations than the central switchboard.
A way to monitor the boat's systems from home or from my bunk.

So I built my own solution to cover this.

CANBoat is a software solution running on a 'standard' Linux system and consists of the following software:

A cellular modem stack to provide as-reliable-as-possible data connection over cellular, as well as a SMS service interface.
A NMEA 2000 'reader' interface that receives all NMEA system data. The data is logged to rrd database and provided to Ethernet clients.
An interface to the PLC (made by Wago) to control power circuits and measure tank levels. The PLC is running software by me as well, which provides the same Ethernet interface as the NMEA and temperature subsystems.
A temperature subsystem that uses the Maxim 1-Wire network to measure temperature in various locations in the boat. The data is logged and provided to Ethernet clients.
A webpage that integrates the above live data in a format that is usable on the small screen of a mobile device.

Here are some screenshots of CANBoat:

NMEA 2000 data coming from various sources

Tank levels

Interior power circuits

As you can see I have some work to do still on improving the layout -- optimizing font sizes etc.

In the next part I'll show some details of the implementation.

NMEA2000 support and DSC calls on a Simrad RS82/87

2010-09-15T00:00:00.002+02:00

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

2010-09-13T11:41:00.002+02:00

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.

Lowrance Sonic Hub & HDS 3.5 software update

2010-09-09T10:20:00.000+02:00

Lowrance released a software update, v3.5. This provides SonicHub (the new Navico sound system) support and various smaller improvements.

Read all about it here: Lowrance HDS 3.5 update.

I'm not satisfied with the audio setup in our deckhouse, and now I need to choose between adding an audio card to the permanently running Linux box & integrating AirPlay, a MP3 player and other software -- or just install a SonicHub.

SonicHub:
+ Works out-of-the-box with iPod/iPad.
+ Chartplotter is 'on' during sailing anyway.
- No 'remote' app beyond controlling iPod/iPad.
- Unknown power consumption in real life.

Linux:
+ Allows audio warnings from system monitor.
+ Allows any iTunes to stream via AirPlay (once the community implements this)
+ Remote control possible, in future maybe even easy.
- More work for me.
- Unknown power consumption in real life.

All in all, I think I'll opt for the build-it-myself option (again) as it is more fun that way. It also works better when the boat isn't sailing & the HDS is off.

Your Help Needed to firm up the NMEA 2000 database

2010-09-08T14:15:00.003+02:00

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

2010-09-07T21:24:00.001+02:00

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.

Programmatically detecting that /bin/sh is actually csh

2010-05-17T13:41:00.001+02:00

As my last post shows, if you write something up about a subject people will find your site no matter what the purpose of the site, or in this case blog, is about.

Therefore I'm going off on another tangent with a subject that I don't have any other place to put in, and that involves UNIX shells.

In my 'day job' we encountered a few customers that, 'for convenience' decided that they like csh so much that they want this to be the default shell. And they do this by making /bin/sh a symlink to /bin/csh, or even just copy /bin/csh over /bin/sh. This is probably most likely to happen on Linux, as that doesn't use /bin/sh as heavily as the likes of AIX, HP-UX and Solaris.

In my opinion what these people do is a very bad idea, as software should be able to depend that the syntax for /bin/sh is always the same. It maybe a superset when it's actually KSH or BASH, but it should certainly execute the minimal Posix shell syntax. Still, we have to write software that could function anyway. Sigh.

Here's what my colleague Nils came up with:

#!/bin/sh

[ "$shell" != "" ] && goto csh

echo "This is Bourne Shellish."
exit 0

csh:
echo "This is C Shell. You are a naughty fellow -- please reset /bin/sh to a Bourne type shell!"
exit 1

A plain goto csh is ok but throws an error message in bourne style shells, so we prepend it with a condition that is only true in CSH. We can't use if, as that has different syntax in the two types of shell. The condition is true on CSH because it has a variable $shell whereas Bourne style shells have $SHELL instead.

Hopefully this helps somebody out there.

Next time I'll get back to a nautical subject, I promise.

Using a 3G UMTS stick under Linux

2010-05-08T10:15:00.002+02:00

I've been trying to get a typical 3G UMTS modem in USB 'dongle' form working with an embedded Linux system. I subscribed to a local service (KPN 'Hi') a while ago. The dongle turned out to be a rebranded ZTE MF628. It works reasonably well under Microsoft Windows and Mac OS X.

Getting it work somewhat under Linux 2.6.26 or 2.6.30 wasn't very difficult either. Getting it to work reliably turned out to be beyond me. I didn't know it yet, but GSM modems have a whole set of standards that are generally based on the bastard child of the original "AT" commandset created 30 odd years ago by Hayes. The ETSI publishes these standards that are 'open' in that they can be accessed by everyone. That's all fine but it turns out that the ZTE has some peculiar issues with how it implements the standards and it's own company specific extensions that are hard to reverse engineer. Also, the serial speeds required for mega bit speeds (I've got 3,6 Mbps service) were beyond the serial drivers so the PPP connection kept going down. All in all a very frustrating experience that cost much more time than I'd anticipated.

There turns out to be a very simple solution: I bought an Option Icon 505 USB modem to replace the ZTE. What a difference! The Option device uses the same AT command set for control but provides an IP device for the data connection. This eliminates the PPP driver and has very good performance. The driver for Linux is written by Option employees and available on Pharscape. Kudos to Option for making an excellent product that works great with Linux.

Lowrance yellow Ethernet cabling

2010-05-06T11:07:00.004+02:00

The Navico 'yellow' ethernet connector used on new Lowrance devices such as the HDS series has the advantage of being watertight and easy to make a reliable twist-on connection:

In case you want to use a standard Ethernet switch, or have guys lay ethernet cabling through some narrow ducting you cannot use the normal Lowrance Ethernet cabling and have to crimp an RJ-45 jack onto the Lowrance cable.

On opening up the cable I found two twisted pairs of cable, as expected, plus a shield:

The pairs are blue and orange. I connected those the same way as a 3 Com sourced very thin Ethernet cable I had lying around: blue to pins 1+2 and orange to pins 3+6 of the RJ-45 jack. This isn't according to either T568A or T568B, but that cannot be helped when the cable pairs are blue and orange. In practice the cable works fine, both when wired directly and when wired to a switch. I don't know whether the is actually a cross over cable or direct through though, so if you use a switch that doesn't do auto MDI-X you may have to swap the pairs.

Here's the crimped connector:

and the final cable:

Once plugged in a quick run of tcpdump revealed the IP address of the Lowrance HDS and a ping proves that my Mac and HDS are able to talk to each other:

PING 169.254.17.126 (169.254.17.126): 56 data bytes
64 bytes from 169.254.17.126: icmp_seq=0 ttl=64 time=0.788 ms
64 bytes from 169.254.17.126: icmp_seq=1 ttl=64 time=0.405 ms
64 bytes from 169.254.17.126: icmp_seq=2 ttl=64 time=0.480 ms

Hurrah, one more item from my to-do list done!

Update

May 2010: Commenters have asked me whether this means they can now interface a HDS or Broadband Radar to their PC. ~~Alas, no. The test done above was just a convenient way for me to test that the munged cable works.~~June 22, 2010: Yes, you can! Navico has released a SDK that allows navigation software providers to interface with the Broadband Radar. As far as I know, only Expedition has released the necessary software so far (August 2010). For more information see Simrad BR24PC, Free Range BroadBand Radar #2 at Panbo.

Basics of Electrical units and quantities

2010-05-01T10:58:00.006+02:00

I'm sick and tired of stories in the general boating press by confused writers that mix up electrical numbers and quantities.

This is probably because electrical units are a bit different than the units used for length, speed and distance.

Here's my feeble attempt at clarifying this apparently confusing matter. I shall compare electrical current to water current flowing in a circular pipe, which seems appropriate in our nautical environment.

Some theory first

Let's start with the three most familiar units:

Voltage - The eagerness with which electrons want to flow from A to B. In our comparison, this is equivalent to the water pressure in a pipe.
Current - The magnitude (amount) of electrical charge passing through the conductor per unit of time. In our comparison, this is equivalent to the discharge of a river or pipe. Discharge is usually measured in cubic meters per second, likewise electrical current is measured in coulombs per second. An electrical current of 1 ampere is defined as 1 coulomb per second. This is important to note: current is a derived quantity. One coulomb is just a large bunch of electrons, about 6.241 x 1018 of them.
Electrical energy - The thing that we have electricity on a boat for anyway. Electrical power is what makes the appliance (winch, coffee maker, light bulb) work. In our comparison, it is the amount of power that a turbine could transfer from the water in the pipe. This is a product of the discharge and the pressure. Likewise, in an electrical circuit the power is the product of the voltage and the current. In units: volt times ampere equals watt (V * A = W). (Note to fellow engineers: I know it should be U * I = P, but let's not further complicate matters.)

Note that although voltage and current are used so often, they are NOT basic units such as volume and length are. In particular voltage is defined as the total energy required to move an electric charge from A to B divided by the magnitude of the charge. Current is also a derived value. In electricity, the basic unit is charge measured in coulombs.

The confusion grows when we start talking capacity. In particular the capacity of our electrical charge containers, more commonly known as a battery. Given what I stated above you'd think that we'd measure battery capacity in coulombs: how many electrons does it take. Unfortunately, historically we have used ampere hours. One ampere hour (Ah) is a current of 1 ampere during 1 hour (3600 seconds). Since 1 ampere is 1 coulomb per second, 1 Ah is 3600 coulombs.

Likewise the total amount of power used over a number of hours defines how much must be recharged, or bought from an electricity company. Historically this is measured in (kilo)watthours. 1.2 kWh = 1200 Wh = 1200 watts for an hour. If this power had to be supplied by a typical 12 V battery bank this would be (V * A = W, therefore A = W / V, therefore Ah = Wh / V) 1200/12 = 100 Ah.

Typical Errors

Taking one article from a Dutch magazine "Zeilen", let's discuss what they do wrong. The article "Geen beweging, toch stroom" (No movement, still current) in the May 2010 issue discusses fuel cells, and shows a few typical examples.

The first small error is a sentence where the author discusses a Gas generator ... with a capacity between 1.5 and 2.2 kWh ... Now kWh is the amount of power delivered over a particular amount of time. Generators are sized in terms of power, e.g. (kilo)watts -- not kilo watt hours.

Then he goes on to discuss the admittedly confusing (but correct) wording used by EFOY fuel cells. EFOY rates their equipment by the amount of watt hours they can deliver per day (24 hours). Admittedly, this would be better expressed in simple Watts. The author writes this as follows: There are five models from 600 to 2200 Watt/h per day, a rather strange and misleading denomination. You should divide the number by 24 to arrive at the true performance. For an EFOY 2200 this coumes down to a maximum current of 7.5 Ah at 12 volt. Ouch: it should be Watt hour, not Watt per hour (Watt/h). It should also be 7.5 A (amps) not 7.5 Ah (amp hours).

Anyway, on to the next section where he claims that the Protonex M-250C fuel cell delivers 250 Watt per hour. Guess he means 250 Watt...

And the last one: The Italian company Acta delivers fuel cells with a capacity of 100, 200 or 1000 Watt during eight hours. Again, Watts per hour is meaningless.

Guess it's no wonder that many boaters are confused about electricity with magazines feeding them mis-information like this.

Cool new way to control & monitor navigation data

2010-01-30T19:58:00.004+01:00

I've just come across this incredibly cool new development kit that has wonderful capabilities when applied to a marine market.

It's the Texas Instruments eZ430 Chronos wireless watch development tool. This is a development tool that includes a sports watch with a wireless connection to a PC.

Three simple marine applications that come to mind:

Show navigation data such as Speed Over Ground, Wind Speed etc. etc. on your wrist.
Control your auto-pilot (via NMEA 2000).
Act as a Man Over Board detection device.

The possibilities are endless as they say.

Choosing an Eco Flat TV

2009-12-06T13:39:00.002+01:00

We're not very avid TV watchers on board, but we do like to watch a movie now and then. And, of course, our children like watching various cartoons and movies a lot.

So we needed a TV. About a year ago I started paying attention to see which ones would be applicable to our low power envelope. At that time it was hard to obtain facts about flat TV power consumption except in general terms. Luckily the increased awareness amongst the public and the reaction towards that from suppliers has benefited us here. Technologically the trend towards using LED backlights has helped.

As developments go quickly I delayed buying a TV for as long as I could. Now that the deadline for me delivering equipment is almost upon us I had to choose. To be honest, I still don't like LCD TVs as much as I do plasma in terms of visual smoothness. They are often 'harder' in showing up digital artifacts, both moiré and compression.

In the end the choice was narrowed down to the one with both the highest potential for power saving and the lowest advertised power usage in the size (32") that we were looking for. The Sharp LC-32LE600E has an official power use of 60W. In practice, running it at the visual settings that we liked best it turned out to use even less at 30 to 37 W. Pretty cool for such a big display - in more ways than one.

Are Eco Ethernet switches Greener?

2009-12-06T10:23:00.009+01:00

There was a recent discussion on Panbo where some people proposed that Ethernet, and more specifically using the IP protocol with a 100BASE-TX or 1000BASE-T physical layer. I am still sceptical of that for several reasons. One of them is that an IP stack rules out using small micro controllers, or requires extra hardware. This drives up the cost of the minimal hardware node. A zigbee or bluetooth based system is much more low-end friendly and has the added benefit of needing no wires.

Ethernet does have a role on-board in tying together both navigation hardware with high speed sensors, such as RADAR scanners and in enabling the interface between on-board computers, Wifi and mobile internet modems and whatever other gadgets turn up on board.

So I've taken the power meter to use again to measure what Ethernet costs us in terms of Watts. Less, much less, than I feared -- if you're careful. There is an interesting trend visible in the past year where many manufacturers are advertising green or eco friendly devices.

The devices that I tested were three "older" devices that carry no green or eco label: a Linksys WRT-54G access point with built-in 4 port 100BASE-TX Fast Ethernet switch, a newer Linksys WRT-54Gv2 access point also with a 4 port Fast Ethernet switch, a Sitecom LN-113 8 port Fast Ethernet switch. I also tested two eco 5 port Gigabit Ethernet switches from D-Link (DGS-1005D) and Netgear (GS105). I used the power adapters that came with the Gigabit switches as these were the newest and most efficient. The cable lengths were mixed: two that were about 5 m and two that were about 10-15 m.

Device	Load 0	Load 4	Load 3 + 1GB
Linksys WRT54g v7	3.0 W	4.1 W	N/A
Linksys WRT54gV2	1.9 W	2.8 W	N/A
Sitecom LN-113 v2	0.0 W	1.2 W	N/A
Netgear GS105	0.1 W	0.6 W	1.0 W
D-Link DGS-1005D	0.1 W	0.6 W	1.0 W

The test results show that four active ethernet ports will cost you 0.9 to 1.2 W per port if you use just any old ethernet switch. You can save power by using a new eco switch and tying any Gigabit capable ports to 100 MBit. A Gigabit port seems to use 0,5 W per port.

To answer my own question: Yes they are -- if you're careful to slow the ports to 100 MBit if that is fast enough for your requirements.

For our modest Ethernet network on board our new ship I'll be using the Netgear GS105 as that has a 12V supply (the D-Link has a 5 V stabilised power input) so it is easier to integrate. All ports will be run at 100 MBit speed to reduce power consumption.

Airmar PB200 WeatherStation power usage

2009-10-15T18:09:00.004+02:00

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

2009-10-15T17:46:00.004+02:00

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 for Linux

2009-10-11T21:49:00.005+02:00

I've ported the packetlogger program to Linux. At the moment the only interface that I have hooked up is the Lawicel CAN-USB, as I plan to use the Actisense interface on Microsoft Windows and thus have no need (yet) for it to run on Linux.

It turns out that the Lawicel (like the Actisense) uses an FTDI chip to interface to USB. I could not get the FTDI D2xx libraries to work properly on Debian (Lenny). The workaround was simple: interface to the pseudo serial port directly, that works fine and is just about the same amount of work. It also means there is less interference of additional layers of software. My code uses a separate process to do the reading anyway, and uses the UNIX pipe mechanism to transport the data to further processing layers.

Now I shall have to start implementing the real application, which is storing the data permanently in a database on a USB stick and upload the same data to a server on the Internet. It will have to use some sort of configuration file that tells the code what data needs to be stored, and how often.

Something like:

local:
heading: every 300 seconds or 10 degree course change
location: every 300 seconds or 100 m change

internet:
location: every 300 seconds or 100m change

General fixes for packetlogger

2009-08-06T13:58:00.007+02:00

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:

Navico Broadband Radar (BR24) test

2009-07-09T20:36:00.009+02:00

I've finally succeeded in capturing our new Simrad/Lowrance BR24 Broadband radar in screenshots that show what it can do in a way that can be understood without needing to know the local circumstances.

Here is a link to the Flickr set that shows them all.

The first picture shows the largest range that showed useful information. Our antenna was about 8 m up in the air. Still, it showed echos 10 to 15 nautical miles away. Mind you, these were large built up areas (small towns). The dikes themselves at 2-15 nm did not show up. Although not impressive, it does show that the range is there. Notice that there were a number of smaller sailing yachts (motor yachts don't tend to use this lake in F5-6 winds) but that these don't show up reliably at this range. In my experience, those do show up with a 'normal' magnetron based 4 KW radome radar. Also the coast and dikes would show up.

The second picture shows the close up detail that is very, very impressive! Going from immediately north to south-east of the center location you see a range of dots and echos stretching from the land shown on the chart into the water. This is a series of metal piles that large ships can moor up to when waiting for the lock. The echos stretching to the land are walkways so that people can load/unload.

To the W @180m to NW @100m you can see the echos of the buildings right on top of the gray building area shown on the chart.

Across the water you can see the mooring wall with the dike behind it. This is where BB shines with it's great range resolution and ability to separate objects behind other objects.

To the right is a Google Map view of the same area.

On all images you can see that man-made objects, in particular heavy or conductive matter such as metal, show up much better than the softer areas (earthen dikes, trees), especially further off.

If you have any questions regarding the objects or views that I have, please comment and I will expand this entry accordingly.

Actisense NGT-1 update for packetlogger

2009-06-28T12:25:00.009+02:00

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.

AIS class B update for packetlogger

2009-06-21T17:52:00.007+02:00

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

2009-06-07T18:23:00.006+02:00

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

2009-06-02T20:03:00.008+02:00

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

2009-06-02T15:45:00.011+02:00

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

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

Hydraulic power pump for the lifting keel.
Washing machine (Miele, with hot fill capability so it can use warm engine water.)
Dishwasher.
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:

Ethernet
NMEA 2000
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

2009-06-02T10:58:00.007+02:00

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:

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.
Should offer a simple switches-and-lights interface that is easy to understand for people that are not comfortable with computers.
Allows integration with modern technologies such as remote controls (locally and remotely) and Google Maps mash-ups.
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.

Apple 30" Cinema HD Display power usage

2009-05-29T13:03:00.004+02:00

Now that I've got the power meter out, I've started measuring more stuff than what's going onto the boat. Maybe having actual figures will help somebody out there.

For instance, my Apple 30" display at the office uses up to 150W according to Apple. The actual consumption figures that I've measured are:

Setting	Quality	Power
0%	On the dim side, but still pretty good	51 W
50 %	Normal office use	75 W
100 %	Good for use with indirect sunshine	114 W

Simrad/Lowrance NMEA2000 network power usage

2009-05-11T19:21:00.006+02:00

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:

The chartplotter only uses 25% of the power envelope
NMEA2000 nodes seem to use at least 0.4W.
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

2009-05-05T18:14:00.006+02:00

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.

Apple 24" LED Cinema Display power usage

2009-05-05T17:55:00.005+02:00

Yesterday I was trundling the isles of Office Center, and noticed that power usage is now getting more attention of office/home TFT display manufacturers. Good!

In particular they had a LG 22" display that only used 22 Watt at full backlight. It was not very bright, but it was fine for office or home use.

As they had a power meter attached, the power claim of 50% reduction was easily verified. At full backlight usage hovered around the 21 W mark. It also showed that it only used 11 Watt at the lowest backlight setting, where it was still somewhat visible.

They had one of the new 24" Apple LED Cinema Displays. An employee asked whether I had any questions, so I asked whether it was OK to move the power meter to the Apple displays to check out how much power they were using. Lo and behold the manager turned up, said yes sure. We set the meter up with the Apple display. The results were:

Setting	Quality	Power
0%	backlight off or almost off; not watchable	11 W
20 %	Normal office use	20 W
40 %	About as bright as the LG at 100%	30 W
100 %	Very bright	88 W

I was amazed by the range actually. Certainly in that store the picture was usable at 20-30 W, meaning you can easily save quite a lot of energy by turning your screen down a bit.