28 September 2010

Low power USB display

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!

27 September 2010

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

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

}

21 September 2010

CANBoat Design part III - Choosing the server hardware

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

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:

javascript gauges

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

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 data NMEA 2000 data coming from various sources

Tank levels Tank levels

Interior power circuits 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.

15 September 2010

NMEA2000 support and DSC calls on a Simrad RS82/87

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.

13 September 2010

Packetlogger update for Raymarine E-80, Lowrance EP-80R

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.

09 September 2010

Lowrance Sonic Hub & HDS 3.5 software update

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.

08 September 2010

Your Help Needed to firm up the NMEA 2000 database

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!

07 September 2010

Packetlogger update: PGN list complete, Linux version available

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.