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.