28 June 2009

Actisense NGT-1 update for packetlogger

Last week I received a NGT-1-USB that Actisense kindly provided for a trial here in the lab. It is a much more capable device than the Lawicel CANUSB that I have been using so far, as it relieves the burden of the programmer of having to negiotate bus commands. As a drawback its SDK is more complicated -- primarily because it supports multiple Actisense devices. Still, I'm very satisfied and if I can write a Linux driver I'll keep it (and pay for it!)

Anyway, I have now updated the packetlogger so that it can use the Actisense NGT-1 or NGT-1-USB for sniffing NMEA 2000 packets. As the NGT-1 already does fast packet assembly I had to modify my analyzer and support a new packet format for the logger. The analyzer will transparently adapt to the new format. The existing 'canreader.exe' program has been renamed 'lawicel-reader.exe' and a new 'actisense-reader.exe' has been added.

The actisense reader needs to know which virtual COM port the Actisense device is on. To find out which port that is you run actisense-reader without any arguments, like this:
C:\packetlogger> actisense-reader
Usage: actisense-reader <com-port>

<com-port> is an integer from the following list:
3: COM3 - Actisense NGW/NGT NMEA 2000 Gateway (Available)

<baud-rate> is an integer from the following list:
4800 38400 115200 230400 (default is 115200)

If your device still has the original baudrate (115,200) you do no need to provide this as it is the default value.

The work done to support the Actisense NGT-1(-USB) turned out to be most of the work needed to support the logfiles that Airmar's WeatherCaster software can create, so I've added support for those as well. Note that the WeatherCaster software, although not very flexible, is useful even if you do not own a Airmar PB-200. It can show other (wind, speed, GPS) data as well.

Here are the links to the new software and NMEA packet support files:
Oh, and as a final bonus I've located some more PGN numbers, so these are now displayed as well. Most of them seem pretty obscure and I haven't seen them on my network at all. Still, when they come by you will know what the packet name is.


  1. Kees:

    Great! I can now try out your logger with my NGT-1.

    I'm looking forward to doing so because I'd like to start writing some code to put NMEA2000 data on a TCP/IP network. Do you have any thoughts along those lines?


  2. Hi Adam,

    Sure, I've given that some thought. The complicated part is not sending out the NMEA2000 data on UDP for a local broadcast, but writing the receivers that actually do something with it.

    In fact, my code will probably start doing what you suggest pretty soon.

    What sort of application do you have in mind?

  3. Something iPhone probably, like you had prototyped using Safari but in Obj-C instead.

    I guess UDP is the way to go. I have only ever written TCP code so am sort of intimidated. I was going to start with a TCP polling approach, slurping in instantaneous N2K data values from a server elsewhere on the boat. But there's little reason to do that over your Ajax approach, as the Ajax version is much simpler and would have the same network overhead.

    Benefits to writing in Obj-C would be bypassing the JS performance issues of mobile Safari (which are MUCH improved in the iPhone 3GS, by the way), UI responsiveness, and perhaps integration with other phone components (like the GPS). But since you'd get better GPS data from the N2K bus anyway, if performance is the main issue then it seems kind of dumb to do Obj-C *without* also doing UDP. Guess I'll have to get my hands dirty.

    Finally, I was looking at the GPSGate TCP protocol yesterday. I noticed that they basically just dump NMEA sentences over the wire. That seems idiotic to me. Why not reformat the sentences into something human readable (XML or JSON)? I realize that there is no standard for this but there isn't one for NMEA over TCP/IP either. I don't see why we should stick with a protocol designed for a bandwidth-constrained environment when we are no longer bandwidth-constrained.

    Would love your thoughts.


  4. Another use for what I'm describing would be an open equivalent to Maretron's N2KView. I think something like that is desperately needed for the desktop as well as mobile devices. I think writing it in Flash/AIR would make the most sense.

  5. Adam,

    I guess I'd better get a move on with describing what I am going to build for myself, as it sounds like what you want as well.

  6. I have written a "Sailing Dashboard" using NMEA 0183, and hope to update it to NMEA 2000 soon, as this does seem to be getting easier. Check it out at www.aviadesign.com

    Thanks for your useful work. I too have been programming since the early days, starting with a TRS-80.

  7. Kees,

    I finally got a small N2K lab network up. Connected the NGT-1 to the network and confirmed with Actisense's included demo application that I am getting data.

    I unpacked the packetlogger ZIP file and tried to run actisense-reader.exe. Result: "The system cannot execute the specified program."

    Any thoughts? I'm on Windows XP Pro SP2. Could I be missing some core library?



  8. Kees:

    I have been looking a bit at the raw N2K packet data from the NGT-1 and noticed an error in your packet data support file.

    Where you have written "1 degree = 0x028b0a = 16666 units", you should have "1 minute = 0x028b0a = 166,666 units". I'm guessing this is actually a rounding error, with 1 degree = 0x989680 = 10,000,000 units being the correct conversion.

  9. Adam,

    I'm cruising in New England at the moment, so I don't have access to my development machine. I suspect that I created the ZIP file on my Mac, so it may have been created in such a way that the PC doesn't recognize it. Try experimenting with the executable bit on the file. I'll produce an updated file when I get back.

    As to the error you reported, that's text only. Your description makes much more sense -- silly of me not noticing that 60 * 166,666 is 10e6. The software should work fine though, although as you point out it doesn't work for you.

    I do have a stream of AIS updates almost ready but which didn't make it out as I was preparing for my holiday.

    In fact, there's much wrong with the current code as I found when adding support for the new AIS Class B and Simrad versions thereof. So please stay tuned for a new version due out somewhere in August.


  10. Hi Kees. Thanks for your help. I was actually able to get your code working by upgrading to .NET Framework 3.5. I haven't had a chance to test it out yet but will try to get to it in the next couple of days.

    I also emailed you separately about the possibility of collaborating on some other projects.

    Enjoy your trip!

  11. Kees:

    I ran some GPS data through the NGT-1 and took a look at the output of analyze.exe. It's very cool! I did notice a couple of oddities:

    1. Position Rapid Update only shows latitude:

    2009-07-27Z15:55:49.683 2 1 255 129025 Position, Rapid Update: Latitude = 37:46.955'N

    2. The position data for GNSS Position (129029) doesn't seem to be correct:

    129029 GNSS Position Data: SID = 173 Date = 2009.07.27 Time = 17:22:23.00000 Latitude = 549:13.223'N Longitude = 05:37.471'W Altitude = 3.471e+012 Type = 5 Method = 3? Integrity = 0 Number of SVs = 40 HDOP = 267 PDOP = 15.37 Geoidal Separation = 140.8

    Or I could be missing something. Thanks!

  12. The program not being executable on older Microsoft Windows versions is caused by a missing DLL. If you get this error, just download MSVCR90.DLL from Microsoft: vcredist_x86.exe