Boat electronics hacking on 33c3


Interfacing the tiller auto pilot Seatalk bus

I’ve set up a small workshop / meetup on boat electronics hacking at 33c3 this year.

33c3 is the 33rd yearly congress for the Chaos Computer Club and collects around 5000 awesome people in a big conference centre in Hamburg.

I’ll do a small presentation on NMEA0183, NMEA2000, some signalk, perhaps a bit why this matters when racing sail boats, and why I’m frustrated with the state of boat electronics. I’ll demo some of the progress I’ve made, what I’m doing next and then try to get some discussion going.

My plan is to bring a small NMEA2000 lab setup, with a marine display and some canbus units. Most likely this will be at the Hackeriet assembly, and you’re invited to come and play with it.

If you’re on CCC, come by and say hello!

Posted in Uncategorized | Leave a comment

Seatalk and the ST2000+ autopilot

I’ve been looking at interfacing my Raymarine ST2000+ tiller auto pilot with the other sensors onboard.

The perceived upside of this is that it will steer based on wind angle instead of compass angle. This is nice on longer distance sailing since you don’t have to adjust the sails all the time.

Of course I don’t do much distance sailing, so it may just be an excuse to go digging into another arcane marine electronics protocol. Would be nice to have it working, though!

The Raymarine autopilots are about as old as the Internet is. Seriously. They came in different forms under the names Autohelm, Raytheon and Raymarine, and seem to have looked the same since the seventies.

Interface wise, it can read selected NMEA0183 messages and it also has a Seatalk bus. Course updates and track can be received over NMEA0183, for remote controlling it you need Seatalk.

Seatalk, or Seatalk1 since there is a later incompatible one called Seatalk NG, is a one-wire
bus with binary messaging. The messages (some) and the electrical characteristics have for a long time been reverse engineered and can be found on

Over the years there have been many small electronics projects to create protocol bridges.
Some of them can only read, some can only write, they only support a subset of the messages and they all have their own bugs. Firmware updates are done through a PIC or Atmel design tool that nobody has. After a few years the author loses interest and they disappear or go out of stock. I’m generalising here, but I think there is a grain of truth to it.

How about we take the following practical approach; 1) get the electrical interfacing documented in updated reference designs, and 2) do all of the message translation in software on a real computer.

Laptops are cheap, and they can easily run on battery for the 2-4 hours a normal can race lasts. Since you have the code, any bug that really annoys you is possible to fix, and over time the shared code base should mature nicely.

When it comes to running it without a laptop for cruising or distance races, a generic small x86 or arm computer can be bought cheaply and can run on 90mA (Intel Edison) to 200mA (older Raspberry Pi). This is in the region of the power usage of a navigational light, so most sailing boats should have the power budget for it.

Getting back to the auto pilot, one of the other sweet possibilities of having direct Seatalk bus access is that the autopilot can (I hope) be configured remotely. See the “88 03” message type on Knauf’s site. This means that gain and wind response can be set from a reasonable user interface on the laptop! I’m pretty good with technical gadgets, but I always have to look up in the manual how to adjust gain if its been more than a month since last time.

You can also send key presses directly over the bus, so when it rains you can change course without getting wet in the rain. From here the path to remote control from your apple/android/pebble watch is pretty short, if you’re into that.

All in all there are significant cool stuff to be had. Now we just need the Seatalk USB transciever design that does collision management, line coding (9 bits to the byte!) and data coding.


Posted in sailing | Tagged , , | Leave a comment

Garmin GND10 unveiled (it is Nexus FDX!)

Mother of all detours; the USB port on the Garmin GND10 isn’t NMEA2000, it is something called Nexus FDX. That took a couple of weeks to figure out, hunting for NMEA2000 protocol headers. Always check your assumptions.

Anyway, I’ve written a decoder for it now which can be found on . It decodes GPS position, speed, wind angle and strength. Output can be a series of json encoded dictionaries, or NMEA0183 if you prefer.

I’m pretty sure I’ve gotten the header format of the FDX packets wrong,  but it seems to work. The git repo above has my notes and some dump files, if anyone has a proper FDX network and want to try it out.

Use case is simple. I connect my laptop to the GND10 USB port before I go out sailing, and I get all the sensor data into OpenCPN. I can also log it to file, if I want to compute my own polars or do endless post-regatta analysis.

Posted in sailing, varnish | Tagged , , , , , , | 4 Comments

NMEA2000 and CANbus

I’ve been looking at NMEA2000 and CANbus lately. I’m attempting to reverse engineer the binary protocol seen coming out of the USB port on a Garmin GND10 network bridge, and that opens a whole field of new and interesting stuff to know about.

Quick background: NMEA2000 is a application-level protocol that is used on ships and smaller boats, to communicate things like heading, speed and position between sensors (gps, compass, etc) and displays on the bridge. The physical, datalink and network layers (to the extent that it applies) in this are CANbus.

It is truly fascinating how complicated “industry standard” can be. Adding to that, each of the 8 ISO1939 standards defining it is 168CHF each. Not an option for me at the moment, so here I go digging in binary data. (And in retrospect, complain less about RFCs in the future. They are free, open and mostly well thought out.)

The Wikipedia nodes for both these contain lots of facts, but perhaps doesn’t give you the overview you need as an implementor.

CANbus can be sent over many different physical setups, for NMEA2000 there are five wires: ground, +12V vcc, can-hi, can-lo and shield. Typically you have a canbus transciever circuit/IC to do the differential encoding on can-lo and can-hi, and a separate canbus controller for the protocol itself. The connectors for NMEA2000 is a round quick-release kind, but you can also do canbus over cheap cat5+rj45 if you want. (250kbit/s is rather forgiving these days)

CANbus frames have a 32 bit identifier and up to 8 bytes (yes, this is quite adorable) of payload. The wire format contains additional bits here and there, a length field and a CRC and DC-correcting tailer. All this is probably interesting if you create the controllers, but for anyone writing software it doesn’t matter. Especially the part about the frame identifier is either 11 bit or 29 bits, you can ignore. At least for NMEA2000 only CAN2.0B with 29 bit identifiers are used.

On the software side, you get: 1) 32bit frame identifier, 2) the length indicator, and 3) the >=8 bytes of data. Everything else is handled by your interfacing hardware. Hurray.

The 32 bit identifier is a bitfield consisting of source, destination, priority and the Parameter Group Number (PGN).

In NMEA2000 most frames are broadcasted without any specific receivers in mind. The PGNs are defined by the non-public standard made by NMEA, and defines the number of payload bits and what they contain.

Which range a PGN is in also define which framing method is used. CAN frames with a PGN in a single-frame range has the single-frame 8 bytes of payload. Some PGNs are in a “fast-packet” range, where a collection of (up to) 32 CAN-frames can be sent with a session id, sequence counter embedded in the first 8 bits of each payload. The first frame in the sequence additionally has a sequence length in the second byte. This allows the receiver to reassemble the sequence in userspace for a combined payload of up to 233 bytes.

I have no idea how controllers handle lost frames in a fastpacket sequence, most likely they just drop the whole sequence. I also wonder if anything here is complicated enough to that out-of-order delivery can happen. Haven’t seen it yet, though.

There is an additional “ISO” transfer mode that is a (“unicast”) request/response method. Back when I was playing with ODB2 in cars, you had to request a specific ID with data. I think this what was being used there, but haven’t verified. It supports up to 1785 bytes, so obviously there is some segmentation and reassembly method there as well. I haven’t looked at it yet, as I’m mostly interested in the broadcasted updates.

On the network management side, there is an ARP/ND alike way for connecting units to claim source IDs. Lower source id means higher network priority on collisions. so there is some magic to it. I haven’t come this far yet.

Trying to keep this short and readable, let me round off with mentioning the CANbus network interface in Linux. There is kernel support now and you get a network interface with a whopping 8 byte MTU. There is even a loopback interface for it, so you can talk CAN between applications if you don’t have a physical CAN interface. Look at the documentation for can-utils.git for details.

I’ll try to post again when I figure out more of this stuff.



Posted in stuff | Tagged , , , , , | Leave a comment

Shutting down

Keeping this short: I’m shutting down my side project running a hosted Munin monitoring service from mid August 2016.

Priorities have changed, and since I don’t run many servers these days I don’t spend the time maintaining it that such a service deserves.

I hope it has been useful service. I know I’ve learned a lot from this experience.


Posted in Uncategorized | Leave a comment

Varnish Device detection looking for maintainer

We’re looking to have someone take over maintenance of the Varnish Device detection VCL set.

The last couple of years we haven’t really served it right, and it is time to let someone with more practical/hands-on experience take over.

I’ve written an explanation in the README.rst file. Short version is that we’re good at fixing Varnish crashes and configuring it. Expert knowledge about User-Agents and what is a reasonable way to group 2015-clients we don’t really have.

Compensation is the usual in open source community projects, minor fame from your peers and some contributor gear. T-shirts and Varnish Cache coffee mugs in abundance shall be yours.

So, if you’re up for it, please drop me an email and we’ll see what we can figure out.


Posted in varnish | Tagged , | Leave a comment

Report from Varnish Developer meeting 2015-12-04



View of Rotterdam Centraal from floorplanner’s offices.

Last Friday the Varnish Cache team met up in Rotterdam to discuss all things Varnish and to work together on ongoing tasks.

There is work being done on merging UPLEX’s consistent hashing backend director into Varnish. After a delightful discussion I believe Nils decided it should be called the shard (sharding) director.

Dynamic backend definition support is moving along and Dridi showed off work done on his new DNS based director.

Further on the load balancing side of things, Arianna is looking at gradual traffic rampup when a backend comes back from being sick.

Guillaume and Dag dug deep into the proposed specification for describing HTTP/2 in varnishtest test cases. This is a prerequisite for a robust HTTP/2 implementation in Varnish.

Github transition is moving along, with migration scripts and work from trac being worked on. It may be a while until Github’s API rate limiting lets our hosts do any requests again, though.

Martin and Poul-Henning spent some time discussing the object storage API to better support the upcoming persistent storage module being made by Varnish Software these days.


Varnish developers hard at work

Thanks to for allowing us to use their facilities in Rotterdam, and to Phil from Dyn for setting this up.

Posted in varnish | Tagged , | Leave a comment

Scanning for multicast TV channels

In recent times, I’ve cut the cord and stopped watching TV from my local cable company.

This gave the need to look for IPv4 multicast groups that had active talkers, so I (on occasion) could stream some live TV over the internet instead. (don’t overthink the logic here .. ;))

The Norwegian research network has some free/open TV channels (NRK, TV2, Frikanalen), and I was thinking perhaps there are more available further out?

IPv4 multicast has a pretty small address space. 244/8 and up to the top. Shouldn’t be to hard to join all of them and see if something comes down the pipe?


1) cook up a libpcap listener that reports destination ip and port of any multicast that is coming in, as well as bitrate. you probably want to filter mdns, sap, upnp and some other ports to keep the false positives low. I’ve made gist with the one I wrote here.

2) Join every multicast group under the sun, one by one. Just bind a socket to it, the port doesn’t matter. Rinse and repeat. I spent 10 seconds in each group, and joined about 50 at the time. I recommend that you go buy your network operations people some beer in advance, as IGMP implementations seem to fall over after a few days of heavy joins/parts. I recommend perhaps 5 or 10 concurrent groups. Code is here.

Some results, either from direct scanning or from scanning subnetworks that were sending SAP announcements:

  • There are some TV channels on Deutsche Welle and NHK World in 1080p.
  • The Hellenic Parliament [sic] TV is on
  • There are quite a few surveillance cameras hooked up, ready for your viewing pleasure!
  • SVT1 is still around in Uninett.
  • Some weird music channel called mtvU. Endless commercials, so probably american? :)

There are some more findings, but I don’t think the owners would appreciate publicity. I’m pretty sure there is more out there, if someone cares to take another look.

Anyway, I’ve had the code laying around for a while. Perhaps someone will find it useful. It worked well enough for me.

Posted in Uncategorized | Leave a comment

Introducing hitch – a scalable TLS terminating proxy.

The last couple of weeks we’ve been pretty busy making SSL/TLS support for Varnish Cache Plus 4. Now that the news is out, I can follow up with some notes here.

The setup will be a TLS terminating proxy in front, speaking PROXY protocol to Varnish. Backend/origin support for SSL/TLS has been added, so VCP can now talk encrypted to your backends.

On the client-facing side we are forking the abandoned TLS proxy called stud, and giving a new name: hitch.

hitch will live on github as a standalone open source project, and we are happy to review patches/pull requests made by the community. Here is the source code:

We’ve picked all the important patches from the flora of forks, and merged it all into a hopefully stable tool. Some of the new stuff includes: TLS1.1, TLS1.2, SNI, wildcard certs, multiple listening sockets. See the CHANGES.rst file updates.

Varnish Software will provide support on it for commercial uses, under the current Varnish Plus product package.

Posted in varnish | Tagged , , | Leave a comment

PROXY protocol in Varnish

Dag has been working implementing support for HAProxy’s PROXY protocol[1] in Varnish. This is a protocol adds a small header on each incoming TCP connection that describes who the real client is, added by (for example) an SSL terminating process. (since srcip is the terminating proxy)

We’re aiming for merging this into Varnish master (so perhaps in 4.1?) when it is ready.

The code is still somewhat unfinished, timeouts are lacking and some polishing needed, but it works and can be played with in a development setup.

Code can be found here:

I think Dag is using haproxy to test it with. I’ve run it with stunnel (some connection:close issues to figure out still), and I’d love if someone could test it with ELB, stud or other PROXY implementations.


Posted in varnish | Tagged , , , , , | Leave a comment