Standards and Simplicity

I’ve been posting weekly to my “live page” with random noodlings about how to proceed with system integration, and lately it’s been clear that once a course is set, I should move the narrative over here. After all, a blog is archived, RSS-able, prettier, and even generates occasional clickage. Friends remind me that we are now in the 21st century and blogs are the way to go… though I persist in believing, perhaps anachronistically, that nobody in some distant tomorrow is going to care much about the uncertainties of yesterday. (Frankly, I still miss the old Microship Status Reports that went out by email!)

All of which leads directly to this posting. Quite a lot is happening, including the arrival of my First Mate, acquisition of the ship’s radios and comm systems, a major upgrade to the lab, a decision on the on-board server, woodstove installation, and selection of a vendor to handle the nav/autopilot/instrumentation systems… so I guess I better start being a bit more forthcoming with bloggage or I’ll never catch up.

There’s an interesting set of meta-issues driving design decisions that will in turn affect many years of my life. It’s not just a specs game; it incorporates philosophy, cultural extrapolation, notions of sustainability, and recognition of geek expressionism. Take the issue of standards, for example.

I have a real distrust of non-open architectures and protocols, and this is my biggest red flag on the NMEA 2000 approach despite its obvious technical superiority compared to the dated clunker that is the old hobbled 4800-baud serial stuff. I’m reminded of PACTOR… I spent, what, $1200 for a circuit board in a box, all because they managed to lock-down a communications protocol that is now, ironically, even being used on ham radio? That business model is ultimately a disservice to the marketplace, even as the huge profits drive their own development and yield admittedly excellent products. It’s good for their company, but is also an effective barrier to innovation since the infrastructure is proprietary, the standards de facto for HF email, and there is no room to experiment beyond what a friend called the “science project” level.

NMEA 2000 is obviously not that bad since it’s CAN-based and a lot of people are buying into it for plenty of good reasons, but it does make me a little nervous that I might find myself with an on-board network that has a high cost-of-entry for would-be players in the market, preventing competing products from appearing in response to needs (just getting a copy of the standard is prohibitively expensive for the experimenter, and some vendors make it even worse by implementing their own non-standard backbone connector variants). Proprietary protocols may seem to be robust because of their carefully controlled evolution and optimization within a product line, but if we have learned anything over the years, it’s that buying into a single-vendor “standard” can be painfully expensive when you later want to upgrade (that is happening to me now on the boat).

In a somewhat grander sense, closed standards can also be sidelined by a lightweight and agile alternative that incorporates the self-correcting nature of a large community (think Linux), thus lowering costs for everybody. On the other hand, “geek boaters” are not a large enough community to ever reach open-source critical mass, so this is a purely academic rant, and a distraction from the more pressing issues like Maretron vs Simrad vs Furuno vs Raymarine vs Garmin. Frankly, the best thing that could happen would be for someone to fully reverse-engineer NMEA 2000 and publish it widely, allowing any small player with a good idea (even homebrewers) to create new widgets or introduce competitive pressure to the current high-priced market. There is a fine line between the two primary effects of an industry standard: simplifying things for customers and protecting vendors from competition. The fact that we are already seeing proprietary variants in backbone cabling is proof that some companies are still playing by the old rules, trying to lock-in customers instead of focusing on making better products.

Anyway, armed with those observations, we can at least make our purchase decisions a bit more wisely, hopefully encouraging true standards adherence.

One of the inevitable projects will be the gateway between the NMEA 2000 network and the ship server. Maretron actually makes a box that does this (with corresponding Windoze code, of course, looking very VB-ish), but how hard could it be to slurp a feed off the USB port and incorporate into a Rails environment that is already wrapped around a hierarchy of sensors and a web front-end?

And that leads to an update in the system department. I’ve been assuming all along that there would be two computers in the geek console – a Mac Mini for music and productivity applications, and something of the ITX flavor (running Linux) for the data collection and control. This of course led to kluges like a KVM switch to share a single LCD, but it seemed both inevitable and culturally correct. Lately, however, I’ve been re-thinking this in response to a craving for simplicity coupled with reader comments on the live page… and I’m now leaning strongly toward dropping the Linux box and letting the Mac Mini do all the work. Not only is it much more familiar territory, but my recent attempts to get educated in the other platform have run into dead ends (ignored emails to vendors and no response to forum postings). I’m actually finding this quite liberating.

I’m looking at Ruby on Rails for this, since the problem is really one of integrating database and web server. Clients include the web front end accessible anywhere (mirrored on land for public consumption, of course), the DTMF/speech tool via UHF ham radio, a very simple console LCD/keypad for configuration switching, and a command-line interface that I can reach through packet. The Mac would be on most of the time (reported to be 13-20 watts), but can frequently be put to sleep when data is sparse and a microcontroller can keep an eye on security bits… frantically conjuring the magic packet to wake the Mac via LAN (or hell, yanking a hardware chain to take the router out of the loop) when it concludes that it’s in over its little head.

All of this leads to the issue of simplicity. I recently loaned The Cost Conscious Cruiser by Lin and Larry Pardey to my partner… it’s an excellent and pragmatic book that offers a wealth of tips from their efficient life afloat. She wrote: Of course, I trust you and your choices, but do find it interesting that you suggested a book that advises against much of the equipment that you are paying fortunes for. This is an excellent point, and needs to be addressed. I replied:

A fair comment.

I try to learn from wise folks all over the map – like Jerome Fitzgerald and his all-sailing purism, the Pardeys are known minimalists who take pride in ultimate simplicity. That’s not really me, but I sure can learn a lot from them; by taking that approach and really living it, they have developed wisdom that maps well to anyone on the water. My suggesting the book is not to imply that I see them as a blueprint, however.

Somewhere is the balance between the extremes, and I feel that I’m in the ballpark after a few false starts over the last decade. By choosing a steel sailboat that can be single-handed, I’m already trending toward lifestyle scalability, even though that involves some hardware that as not as reliable as what Lin and Larry advocate.

I am also careful to think in “layers,” which you can visualize as successive wrappers that add functionality without being absolutely essential to staying alive and afloat. That’s why I have a sextant, will keep simple DC switching of navigation lights, and like the stand-alone Furuno radar even though I can’t merge its display into the chartplotter. Even the choice to install a woodstove (expensive and probably very much in the way) is a balance between pushbutton convenience (Webasto) and the ability to adapt long-term to fuel scarcity and the need for self-sufficiency.

So through all this, I listen to the gurus. At one extreme are the books mentioned above and the tales of minimalists who have circled the globe (Moitessier et al). At the other extreme, we have Ben the marine electronics guru, the tech-heavy Dashews, and the clear systems advice of Nigel Calder. I pick and choose to find the balance that works for me… sustainability tinged with the buzz that comes from life on the technological cutting edge.

This is getting long, and gritty tech details belong on static pages even though I’m itching to write about the emerging design. I do need to blog soon about the suite of comm tools, though – it’s a mix of radios and related toys that maketh this old ham ticker to go pitty-pat. Now I just want to get to the point where I actually have time to play with it all.

73 and Fair winds,
Steve
N4RVE maritime mobile (soon)