fdxread 0.9.1 released

I’ve released version 0.9.1 of my Nexus FDX protocol decoder. It does things like read .nxb files a lot quicker than before, handle USB disconnects/reconnects of the GND10 (when running), serial port timeout, and lots of other stuff.

As of an hour ago, it is on pypi and can be installed using “pip install fdxread”.

It should work on your laptop, or on a pi if you prefer. (at least it installs fine on my older armhf jessie system.)

In other news, I’ve created a Wikipedia node for FDX to make it more widely understood: https://en.wikipedia.org/wiki/Fast_Data_eXchange

As I said earlier, if anyone have any FDX capable Nexus gear they’re not using any longer, I would love some actual hardware to play with.

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

Regatta race course by SMS

Cowes Week does something interesting; they’re sending out the chosen race course over SMS to the contestants[1].

The cool part about this, for the racers, is that it allows for automatic adding of waypoints on the yachts. Through the years, sailing on different yachts, more than once have we been late or unprepared to the start because the skipper was busy plotting the waypoints manually on the chart plotter. We have computers, they’re good at such. This shouldn’t be an issue.

When the race committee decides on the course, they text this to all contestants automatically. The best specification I’ve found on the format is in the Expedition manual[2], repeated here for reference:

The format is
IRC 3; Saturday; 8Y(RS); 8S(RS); 44(RP); 31(RP); 3H(RP); FINISH at 80
Class;Day of week; markref(rounding);markref(rounding);…markref(rounding);Finish at markref
First field: name of class
Second field: Day of week
Third to n-1th field: mark of the course
Nth field: finish mark in the format shown

The rounding definitions are: RP or RS meaning round to port/starboard, PP or PS for pass to port/starboard, LP or LS for leave to port/starboard, and GT for gate mark.

If you beforehand have plotted all the marks/buys under the correct names (or imported a waypoint file), this gives you everything you need to know except for where the start line is. With this information available, the obvious step of computing reaching angles and which sail to use becomes a whole lot easier.

1: http://forums.sailinganarchy.com/index.php?showtopic=148368
2: http://www.expeditionmarine.com/Downloads/Expedition.pdf

Posted in sailing | Tagged , | Leave a comment

Looking for FDX data dumps (Nexus .nxb files)

I’m looking for data dumps containing FDX protocol data.

Last year I wrote a FDX data decoder in Python (see Garmin GND10 unveiled (it is Nexus FDX!)), and with the sailing season starting there is some interest in improving it.

First of all it would be nice to validate the assumptions made by looking at FDX data from a non-GND10 source. There are duplicates of the data seen from the GND10 in different messages, I think this is the GND10 rewriting data to support some legacy systems. It would be nice to figure out what are duplicated and what is needed. Also my paddlewheel was attacked by barnacles, so I think all my FDX dumps have speed-through-water (STW) at zero.

When that is sorted, a possible next step is to start writing/encoding messages to FDX, to program an NX2 server. I don’t have the gear for it, so I probably won’t spend too much time on it, but as a matter of curiosity it would be nice to have. If anyone have some old (working!) Nexus gear they can spare or upgraded from, ship it to Norway for me to play with. :-)

Data dumps can either be extracted with GND10read’s dumpserial.py, or simply by saving a trace file with Nexus Race from Nexus/Garmin into an .nxb file. Upload to filebin.net and send me the link.

Be aware that I may bug you to go sailing with the log/wind sensor/gps turned off later on, to figure out data fields and what unit originates the messages. It takes some time and scientific rigor to get right, but it is as good a reason to go sailing as any. :-)




Posted in sailing | Tagged , , , , | 1 Comment

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 www.thomasknauf.de/seatalk.htm.

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 https://github.com/lkarsten/GND10read . 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 , , , , , , | 10 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 hostedmunin.com

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 Floorplanner.com 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