maanantai 30. syyskuuta 2013

Yay, working multigauge with chart display

Well, I got the things done I outlined in the last post.

I had two sails with a working setup: Pi with incoming N2K and NMEA 0183 data feeds providing a browser-based navigation display over the Pi-hosted wifi hotspot. I captured the data sets from both occasions, so now I have two real world data sets to play back and tweak functionality with.

Basic functionality in the general purpose multigauge is done, it shows now
  • speed over ground
  • depth with sparkline
  • heading
  • bearing & distance to waypoint
  • true & apparent window
  • laylines with history sectors
Real world data brought out a bunch of simple bugs, such as errors in the true wind calculation. Some known bugs still exist, like updating the layline sectors when the sector should cross origin (0 degrees).

Just staring at the data got boring pretty fast, so I added a map pane with Leaflet using open nautical chart layer from Finnish Transport Agency. I also wanted to see the data on my IPad navigation apps, so I added UDP broadcast with just a few lines of code.

The screen capture video below shows the course plotted on the chart and streaming navigation data on the SVG multigauge. 


Working with this stack has been a breeze: data from different sources (json from Canboat, raw nmea from gpsd, multiplexed json from file) is converted to streams that can be mixed and matched with Bacon. SVG is easy to experiment with and I got a dip into real D3 in addition to its JQuery-like select-and-manipulate functionality when I implemented the sparkline with a time window.

The fusion of different messages from two different data realms is not clean or clear, but utilitarian: just pull the data you need from the messages that you need and ignore everything else. Where this falls apart is outputting data as NMEA 0183 sentences as UDP broadcast on the wifi: there is no translation yet from N2K PGN's to NMEA 0183 sentences so only data from the plotter is available on my IPad, no tridata info.

I guess the main point here is that streaming navigation data with a Pi to browser is rather straightforward and opens up a lot of possibilities. Instead of code-compile-deploy2emulator-start cycle that you need to work with on mobile apps you just save the js/html/svg, reload and changes are there on the browser. And not just one platform - even if my multigauge is pretty simple it has worked on all the browsers & devices I have tested it with. 

I also noticed that Navico has a pretty similar strategy with their Wifi1 product: it makes NMEA 0183 and N2K data from their plotter/MFD available on wifi. Wifi1 retails about 200 euros or dollars, but it seems you need a modern MFD to connect it to. 

With a Raspberry Pi, Actisense NGT-1 and RS-422 to USB converter or two you can route all the data from your existing instrument set to wifi for less than 300 euros  and have it on your IPad in app - or you can roll your own displays armed with Javascript, SVG and Node. The expensive piece of kit is NGT-1, so plain NMEA 0183 is a lot cheaper.

Next steps for me: 

  • clean up the code so that it is fit for exposure on Github
  • tridata PGN translations to NMEA 0183 for IPad apps




2 kommenttia:

  1. I came across this after coming to the same conclusion (NGT1/canbus with Pi), you've made a lot of progress! Did you end up releasing any of this on github?

    VastaaPoista
  2. Oops, I never linked the Github stuff here. Navgauge is at
    https://github.com/tkurki/navgauge

    Things have moved forward with other open source navigation software developers resulting in SignalK, a spec for interchanging navigation data and upcoming ref server implementation.

    See:
    https://github.com/tkurki/navgauge/issues/4
    http://signalk.github.io/
    https://github.com/signalk/
    and SignalK mailing list/Google group at https://groups.google.com/forum/#!forum/signalk

    VastaaPoista