05 November 2012

Navico NAIS 400 reviewed

Thanks to Navico I've (been) upgraded from their NAIS-300 to the new NAIS-400 AIS transceiver and the NSPL-400 AIS splitter. I've been testing both devices for weeks and am now ready to report my findings.

State of the art in 2008: the NAIS-300

For a long time since its introduction in 2008 the NAIS-300 was the only AIS device on the market that had a NMEA 2000 interface as well as an NMEA 0183. At the time all AIS class B transceivers only had NMEA 0183, a fact easily explained by the fact that at the time all transceivers used the same OEM board manufactured by SRT.

Even before Simrad and Lowrance became part of the same industrial group both companies were early believers and adopters of the NMEA 2000 standard, in some case years earlier than others.

The NAIS-300 was probably the first "joint" product that was going to be used by both brands in the group, and it was also based on the SRT board. In addition to that board it contained a second circuit board that contains the NMEA 2000 interface.

That the NAIS-300 was the first (and only) meant that it did have some rough edges on the NMEA 2000 interface. As the NMEA had not yet agreed on or had time to standardize the PGNs necessary for class B AIS there were only PGNs for class A. Apparently the NMEA assumed that the existing PGNs could be used for class B as well. Thus the NAIS-300 was released with a company specific PGN 130842 for use with class B. It did mean that when used with a non-Navico display you would be able to see a class B device, but you would not be able to see its name, callsign, size of ship etc. The Simrad, Lowrance and B&G plotters understand the 130842 PGN and thus show all information transmitted by class B transponders. There were some additional issues with the NAIS-300 sending out a heading for ships that do not have a compass interfaced to the GPS. All in all the NAIS-300 is better off when combined with a Navico (Simrad/Lowrance/B&G) MFD when interfaced over NMEA 2000. If you don't, or care about the minor rough edges, I recommend you use the NMEA-0183HS output instead.

Fast forward four years

Earlier this year Navico announced the new NAIS-400 and their first AIS splitter, the NSPL-400.  The NAIS-400 is again sourced from SRT. The new SRT board offers NMEA 2000 so the Navico engineers didn't have to tack it on, but they do write extra software for it or let SRT do this, as it still supports the Navico specific PGN 130842. Of course it also sends out the now approved standard PGNs 129809 and 129810. The NMEA 2000 interface is almost on par with the NMEA 0183 interface. [Update 2012-01-02:] I say almost because the NMEA 2000 interface does not yet transmit the GPS DOP (precision) data, unlike the slower serial ports. The GPS position data was added in the Nov 31, 2012 software update version 2.5, but DOP is still missing.

An interesting feature of the NAIS-400 is that it has basically three serial NMEA-0183 interfaces, one of which is USB and the other two RS-422. NMEA-0183 data received on the RS-422 ports is sent out over the other ports. This means that you can use the NAIS-400 as a general 2 port multiplexer.  You can change the speed of the RS-422 ports in case you want a different speed than the standard 38k4. I had no issues running the RS-422 port A directly with a RS-232 port on my Linux system, but as usual you might have to insert a level converter if you have no success.

I measured the power consumption of a NAIS-400 with all interfaces (NMEA-0183, USB and NMEA-2000) running as 0.17 A at 12.2 V. The splitter power consumption was 0.13 A at 12.2 V.

Together this is still less than the consumption of the NAIS-300 which I measured to be 0.45 A.

So by itself the '400 uses one third of the power and has more features. What's not to like? Well maybe the physical packaging which uses a circular connector and a wire tail that you splice onto your own wiring. The problem with that is that this requires extra connections that are best hidden from sight in a duct. Any my duct near the installation location is rather full.

So installation wise I prefer the older one, but that's really the only bad thing I can say about the new transceiver. Overall, highly recommended.

13 October 2012

Crowdsourcing bathymetric data

It seems that the newest thing in the marine navigation is going to be that the boating users are going to provide their own depth data to themselves as well as to the general boating population. In other words, we're goin' Cloud Crowd Surfing!

As part of the recent Lowrance HDS Gen 2 Touch announcements Lowrance announced an initiative named Insight Genesis and have now produced a FAQ that explains what different options there are. Basically the Insight Genesis product will be a way to produce your own maps, using your own data. When you buy in to the program you will be able to download the maps generated using the data that you uploaded earlier onto compatible Lowrance chartplotters. Navico will also use the data generated through this program to improve the 'normal' charts that they provide.

Now today I learned from Navionics that they are going to provide SonarCharts, a high resolution bathymetric layer that will be provided via a webapp, as well as Android, iOS and Platinum+ charts. Source of the data will generally be the users themselves. The idea is that you will upload depth data obtained whilst boating, and that same data will then be used overnight to create updated charts.

I can't help thinking that these are somehow linked, as Navionics is the chart data supplier for large parts of the world for the Navico chartplotters. It might well be that the data uploaded for Insight Genesis will be used for SonarCharts as well.

Will be interesting to see how this will work in the fast changing sand banks that are my home waters. I'm saying that because some of the time the Navico Freshest Data seems to be really fresh, with buoys updated within a week, and sometimes not so much. Not being dependent on data supplied by the hydrographic office might speed this up considerably.

14 September 2012

VHF DSC group MMSI numbers demystified

My sailing club is organizing internal training sessions on how to operate DSC VHF equipment. During the development of the training material it became apparent that even the instructors had a warped view of the capabilities and operation of DSC groups. I'm going to use this post to dispel some of the common misconceptions of DSC groups, and explain how they can be used in practice.

Misconception #1

A DSC group is like a mailing list, in other words a group call works by sending out the MMSI of the parties that you want to speak to. Not true, the DSC system can only send out a single MMSI target ID.

Misconception #2

A DSC group is decided by the sender. Not true, it is up to the receiving party to decide which MMSI group they are part of. Depending on the VHF equipment it could theoretically be part of more than one group, but in practice you can set only one group ID.

Misconception #3

Group calls are private. Not true, like all VHF traffic anyone can listen in on the voice part of the communication.

How DSC calls DO work

Let's start with a small recap on DSC operation and MMSI numbers, as these lay the ground work for MMSI group numbers.

VHF traffic uses a number of distinct channels. Most of these channels are used for voice communications, but in the last two years three channels have been appropriated for digital radio to radio traffic.

Channel 87b and 88b are used for AIS.

Channel 70 is used for DSC, or Digital Selective Calling. As the name implies DSC is about calling other radios, with a certain selectivity. This can range from all radios, for instance if you declare an emergency, to a single radio when you call up an individual radio.

All stations call

Almost everyone that owns a DSC VHF transceiver should be familiar with the "all stations" calls. One reason for this is that red emergency button. The other is the obnoxious wailing coming from your VHF if someone else uses that button, or if the local coast guard broadcasts an all ships weather or safety bulletin.

Here's some ASCII art that shows what happens when a maritime safety warning is broadcasted by the coast guard (assuming that Gizmo, Merrimac and Rainbow Warrior are the only vessels in range of the sender:

MMSI          To               Activates 

                          /--> 367412350 = Gizmo
Coast Guard   ALL         |
002442000 --> 000000000 --+--> 244163000 = Rainbow Warrior
                          \--> 244060807 = Merrimac

In other words, all VHFs know that the call is for them and that they should 'handle' it by doing something because they decide that the 'target' includes it.

Individual call

Most people know that you can call a single DSC VHF by entering their MMSI number. If you have an AIS receiver you know the MMSI of all vessels whose AIS transmissions you are able to receive. It's then a question of entering that MMSI and placing the call.

In ASCII art this looks like this when the Coast Guard calls Gizmo:

MMSI          To               Activates

                          /--> 367412350 = Gizmo
Coast Guard               |
002442000 --> 367412350 --+    244163000 = Rainbow Warrior
                               244060807 = Merrimac

Group call

And now you can probably already guess how a group call works. Like all DSC calls it is received by all VHF stations that are within range, but only those stations that have programmed it will show it on their display and warn the operator that they are requested to go to a particular channel.

If Gizmo and Merrimac have programmed 024400001 as their Group MMSI and that number is called by the coast guard the diagram looks like this:

MMSI          To               Activates

                          /--> 367412350 = Gizmo
Coast Guard               |
002442000 --> 024400001 --+    244163000 = Rainbow Warrior
                          \--> 244060807 = Merrimac

The MID in a MMSI 

All MMSI contain a three digit MID (Maritime Identification Digits) that show which country the MMSI originates from. The MIDs are assigned by the ITU. Countries that have large numbers of MMSI vessels use more than one MID. For instance the Cook Islands use 518 whereas the USA uses 366, 367, 368 and 369, and my own MID is from the Netherlands which uses 244, 245 or 246. Thus Gizmo can be seen to be a US flagged vessel whereas Rainbow Warrior and Merrimac are from the Netherlands.

MMSI formats

MMSI have several formats:
<MID><xxxxxxx> = Normal ship MMSI
0<MID><xxxxxx> = Group MMSI
00<MID><xxxxx> = Base Station MMSI

How do you obtain a Group MMSI?

As you can see from the MMSI formats above a Group MMSI contains a MID. It is up to the MMSI assigning office how they go about the assignment. As with more things the way this is done is somewhat culturally defined.

In Australia, the assigning office is the AMSA and they do not register group MMSI. Instead they recommend the following practice: take an existing individual ship MMSI, lop off the final digit (which is usually zero in the USA) and add a zero at the start.

In the USA, where the FCC doesn't even really want to bother with assigning individual MMSI it seems that they also advocate self-assignment using the lop-off-last-digit method. I cannot find a 'definitive' online source for this, but it is suggested in various forums etc.

In the UK, the Ofcom registers group MMSI but they do not publish a list. It appears they have issued a few hundred group MMSI to institutions like the RNLI, various sailing clubs and regatta committees.

In the Netherlands, the Agentschap Telecom issues MMSI. At the moment of writing they have issued two group MMSI numbers, requested by the author.

If you know of the practice in some other country please let me know.

What can you do with a group MMSI?

A group MMSI is useful for any group of boaters where it can happen that someone wants to contact the others in the group, whether for safety or leisure purposes. 

This is especially true if you are in an area where the local authorities have issued a directive that you should continually listen on a particular working channel, and your VHF does not support dual watch or only allows a fixed channel list on dual watch. [If you are from the USA you may find this weird, but in some European countries it is illegal for VHFs to support scanning and/or free channel dual watch.] In such a case a group MMSI can effectively be used to call everyone onto a channel that can be used for routine traffic.

13 September 2012

Simrad IS40 navigation display preview

At last week's HISWA in water boatshow the news from Navico was the new Simrad IS40 navigation display. It is a variation on the B&G Triton display, and is nearly identical.

Thus it has an excellent screen with a 170° viewing angle, uses little power (150 mA with lights on and 50 mA with lights off) and has nice clear and large displays.

At the moment there are two differences between them: the IS40 will be priced lower, but does not show the true wind angle arrow on the composite wind display. It was also hinted that the feature sets of both versions of this display would diverge in future software revisions of the firmware, with the Triton gaining additional high end features targeted towards racing sailors. The target market for the IS40 is recreational sailing boats and motorboats. This is the same market segmentation as seen with the  Simrad NSE / B&G Zeus chartplotters.

 Simrad IS40 with AWA shown digitally and as a vector, TWA shown digitally.

B&G Triton T41 with both AWA and TWA shown digitally and as a vector.

Other than this I could not find any difference between the two.

One thing that did strike me with these displays is that the above composite wind display is fixed, you cannot change any of the data points to show something else. This is strange as you can change the content of the data fields shown on other displays.

Update 19-Sep-2012:
These displays, together with the accompanying OP10 auto pilot remote, have now been officially announced at the Southampton Boat Show, and can be found on the Simrad Yachting website. The IS40, like the T41, has a female and male Micro-C connector. It apparently comes with a 90° angled NMEA 2000 connector to Simnet cable for easier integration into a Simnet network, but I haven't seen it so I cannot say what depth you need behind the display.

15 April 2012

A Fork in the Road for Packetlogger

As I'm going to be busy at my day job for the foreseeable future, I won't be commercializing my packetlogger code. For that reason I've decided to fork the current packetlogger code and publish almost all of it under the GPL as well.

Update 17/04/2012: This now includes the necessary program to interface with the Actisense NGT-1. It does not yet contain the CANusb interface program until I find my CANusb again and have the capability to test it again!

This is now available over at http://github.com/canboat/canboat. The open source version will use the CANBoat moniker that I came up with a few years ago.

I look forward to cooperating with the people that have asked me for an open source version the last couple of years.

Packetlogger update: Microsoft Windows issues resolved

Last November I changed the compiler used for packetlogger on Microsoft Windows from MSVC to Cygwin and gcc. This resolved a whole heap of problems with the redistributable libraries; you needed the right MSVCRT.DLL on your system or it wouldn't work. It also made the building process for me a lot easier.

Unfortunately, it also broke the actisense-reader.exe program that reads the data off the Actisense NGT-1, as that still used the ActisenseComms.DLL which in turn was still compiled using MSVC. This week I was informed by two readers of this, so this morning out came the soldering iron. Errr, I mean the compiler suite!

To be frank I wasn't very happy with the existing status quo anyway -- there were two distinct programs accessing the Actisense device; one on Windows, using the ActisenseComms.DLL, and one on the other UNIX (Linux/OS X) platforms using my own access code, bypassing the DLL. I'm personally using the Linux version for real, so the UNIX version was extended over time to be able to write to the NGT-1 as well as read from it. As you can imagine I didn't much fancy extending the Windows code with the 'write' capabilities when I wasn't going to use it.

I also didn't fancy having to extend the source code with #ifdef Windows and putting Windows specific serial port access in.

Luckily there was an easy solution to this problem. Cygwin's UNIX emulation is so perfect that I was able to port the UNIX source code within 10 minutes!

So from now on there is only one program used to talk to a NGT-1 and that is actisense-serial[.exe].

This does mean that you Windows folks will have to adjust a little. Unlike actisense-reader which showed you a list of COM ports when called with zero arguments you will need to know where your NGT-1 is connected to by some other means. You can do this by going into the Device Manager and hunting down the COM ports there, or you can start Actisense's NMEA reader and note which COM port you need from that.

Once you have the COM port, for instance COM7, deduct one (Cygwin, like Linux, numbers its serial ports from 0, not 1 like DOS and Microsoft Windows) and use that as follows:

actisense-serial -r /dev/ttyS<N>

For instance:

actisense-serial -r /dev/ttyS6

I recommend using the -d debug option so you can see whether opening the port is succeeding if you have any issues.

The new packetlogger binaries can be downloaded from the usual spot:


12 March 2012

Showing AIS targets: Can you have too many?

In some discussions about AIS Class B (as carried by yachts) it has been said that large ships might want to apply some filtering of AIS targets in order to make it easier for the watch to determine which ships pose a navigation hazard and which do not. It has even been suggested that big ships might switch off the display of Class B targets altogether. Here are a few such discussions:


I don't think that keeping a certain class of targets hidden is such a swell idea, but I have to admit that there are circumstances where filtering makes a lot of sense. In particular, during our summer cruise last year we encountered two days where I would have loved (easier) AIS filtering or at least improved display of AIS targets.

First let show you a few images of us motoring out of Lymington (UK) last summer. As it happened the Fastnet race had just started. The RORC has made an AIS transponder mandatory for race participants, and in 2011 a record number of 311 yachts participated. That a lot of yachts were competing was easily discerned on our chart plotter:

Fastnet Race 2011 AIS targets

Oh dear.

On the plus side, I am happy to report that both our Lowrance HDS 8 (gen 1) and iNavX were happily plotting 400 targets. However the display of this data didn't scale that well.

In the screen above, can you make out where we are?

When we zoomed out the picture on the HDS became even more of a black cloud:

Fastnet Race 2011 targets zoomed out

I don't have any screen dumps of our iNavX display. It was better, but not by much. In both instances the lists of AIS targets were almost unusable, with 300+ items in the list. Expedition's AIS handling was so fluky that I ignored it completely.

Now it must be said that the start of the Fastnet was by far the busiest display I have ever seen. Let me show you a more typical image, here with AIS at its best. This is us crossing the English Channel, at the prescribed 90 degree angle to the TSS (Traffic Separation Scheme):

As you can see we've got three (big) merchants coming up on our starboard bow. As you can see this image is a lot more readable.

Update 2012/03/14: Note that the HDS is configured to show vectors for all ships. I guess in order not to clutter the screen too much the vectors are not the same length as the 5 minute predictors shown for our own vessel in the center of the chart. They are much shorter. This means they can be used to visually ascertain the relative speeds of the AIS targets, but it is not easy to relate them to your own speed.

Update 2012/03/23: And this is how it showed up on iNavX. (I thought I lost these pictures but it turned out I just hadn't imported them from my iPad. Found this out tonight when restoring my backup onto my new Retina iPad.)

Using the chart plotter and iPad we were able to determine that we would come uncomfortably close to the middle of the three targets on a converging course. In the HDS image above it is over 5 nautical miles away, but we would get as close as half a mile. For that reason we started our engine and increased speed in order to keep the CPA (closest point of approach) above one mile. We always do this early on so that the merchants clearly see what we are doing. In the iNavX screenshot you can see the fast ship on our port beam, quite far away already.

Note that in circumstances such as the above you cannot just read off CPA from a list to determine the level of danger that a target poses. In the screenshot above the merchants are making a 20 degree course change to starboard because there is an angle in the TSS.  This means that targets that would pass us by far away on the old course might get uncomfortably close on their new course, or the other way around. When building up a mental image you need their speed as well.

What I think could be improved in the display of AIS targets in the Lowrance HDS, and by extension most other displays is:
  • Make the AIS targets a different color.
  • Make the AIS targets somewhat translucent, so you can see through them even if there are a lot.
  • Color them differently based on the threat level that they pose, using a sliding color code.
  • Show proper 5 or 10 minute predictors for targets that could get close.
  • Be able to show a label with CPA and/or speed for all targets at once.
  • Be able to customize the level of alarm an AIS target will create
  • AIS representation needs scale well from 1 AIS target to hundreds.
Personally I would like to see a display where the information for the 5-10 targets with the "worst" CPA and lowest TCPA would be shown with more detail than the remaining ones.

I'm sure that as manufacturers get more experience with AIS they will improve their implementation. Let's hope that the above real world experiences give them some food for thought!

05 March 2012

New license for Packetlogger

For a while now I have been mulling over the exact license that the packet logger utilities and the reverse-engineered PGN information that I created should be available as. I have now decided to release the software and data descriptions under a Creative Commons Attribution NonCommercial-ShareAlike 3.0 Unported License.

What this means is that you can use my data or programs as long as you make it clear where you got the information and programs from, and that you must license your work under such a license as well. All commercial use is prohibited.

The main reason for doing this is to make it very clear that my intention with releasing the list of PGN data fields is not to undermine the NMEA nor their licensing policy [which claims full copyright over the NMEA 2000 standard], but to make the development of 'open' software possible.

Developers that want to develop a commercial product based on NMEA, in my opinion, should become a member of the NMEA and buy the necessary documentation from them. The only thing holding back commercial developers is cost -- there is a fee associated with becoming a NMEA member, and for the documentation as well. One could argue that the fee structure is wrong (as it favors big companies over small companies) but I think that is something for commercial developers to discuss with the NMEA.

However, someone who wants to develop an open source program or utility cannot become a member and obtain the documentation, as members of the NMEA are not allowed to divulge the exact content of the PGNs to non members. Thus for the open source community there is no alternative but to reverse engineer the data structures from scratch.

This now is what I have done -- just by looking at the public documentation that the NMEA has provided and then trying to make sense of the bits you find on an actual live NMEA 2000 bus. Such reverse engineering is perfectly legal, and in my opinion moral as well as long as I do not claim that it is 'official' NMEA information.

Is the NMEA right?

Obviously the NMEA does what it feels is best for their organization, and they have the right to exercise their copyrights.

However, I do think it is a mistake not to have a process or program in place that allows any open source development on top of the NMEA 2000 protocol.

It also frustrates advanced users that want to see how the very expensive stuff that they have bought interacts with each other, and why certain things are maybe not working the way they should.

Source code?

For now the source code for the programs is not released yet. I will probably do so at some point, with the exception of the Actisense NGT-1 interfacing programs. The NGT-1 interfacing programs use material that is copyrighted by Actisense, and I have signed a NDA with them -- and thus I cannot reveal how the NGT-1 works.