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:

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


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


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

http://www.keversoft.com/Keversoft/Packetlogger.html


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:

http://setsail.com/class-b-ais-filtering-the-myth-is-real/
http://www.panbo.com/archives/2010/12/class_b_ais_filtering_the_word_from_dr_norris.html
http://www.panbo.com/archives/2009/04/ais_solas-style_class_b_is_not_ignorable.html


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.

28 November 2011

Packetlogger documentation: nmea0183-serial and iptee

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

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

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.
ArgumentPurpose
-rawShow the raw bytes of the message data following the parsed data
-debugShows 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.
-jsonFormat 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.
-explainProduce the human readable list of PGNs that the parser understands.
-explain-xmlProduce 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

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?

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

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

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.

22 June 2011

iNavX on the iPad

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.