Nomadness Report – Issue 2

The new PDF publication was off to a good start, and the second issue dove into fuel monitoring. On the opening page, I wrote…

Welcome to the second issue of the Nomadness Report, and thanks for subscribing! In the few days that have passed since the first issue, I’ve had a chance to further clarify my thinking on what separates this from the blog and other publications.

Basically, this is higher value technical information than the blog. Although I do have long-term plans to publish a collection of design packages with associated kits, I know how daunting that sort of thing can be when I’m also living the project (or sailing… there’s a concept!). Rather than wait for a time when I can produce and market the books, I’ve decided to put that class of content right here while it’s fresh (though the design packages will eventually include schematics and software listings for those who want to dive in).

On the assumption that most of my subscribers have strong technical interest in various aspects of this project, I’ll make this my most substantial publication… the blog will continue to be the public face, focusing on overviews, tales of adventure, and the transition aboard. Meanwhile, this will carry hacks, design details, geek humor, and the whole twisted gonzo-engineering narrative.

by Steven K. Roberts
May 3, 2011

Historical Perspective

The idea of incorporating diverse devices into a single user interface actually goes back to my BEHEMOTH bicycle, circa 1990. After 16,000 miles on two previous versions, both architecturally inflexible, I wanted to build a system that could push all my geek buttons with a minimum of wheel-reinvention.

This meant that everything had to interoperate, no matter what company built it or what “standards” might be involved. I would acquire a widget, strip it of plastics and power supplies, find the hooks, and integrate it into a system so it could share serial, audio, or other data with its neighbors.

A key component here was the crossbar network, which grew more robust in the Microship project that followed. Using the Mitel 8816 crosspoint switch and some FORTH code, we built boards that could let anything talk to anything. Want a security event to trigger a call to the cops? Just turn on the speech board, connect its serial port to the bicycle control processor, route its audio to the cellular interface, transmit a string to the phone, and watch the fun!

That was 20 years ago and the bike is now in the Computer History Museum along with my first homebrew computer, but we still have exactly the same problem despite vastly better communications. In general, stand-alone devices are available for a huge range of applications, but do not come with associated software objects that can live in a browser. This is unfortunate, and is why I have to build Shacktopus.

I coined that name in 2005 with the intent of creating a sort of “abstracted” communication and data-collection laptop. But the project was aborted due to a death in the family, and besides, now we have smart phones and don’t really need to do it anymore.

Starship Enterprise on a Sailboat

It’s been a long time since I was that grinning fellow, but I have the same crazy desires. I want to blend all my passions into a technomadic lifestyle, and if I don’t pay attention to system integration, that will translate into a huge mess. Data collection from inside and outside the ship, monitoring plumbing and fuel flow, power management, coordinating communications, creating a context for piano playing and podcasting, integrating existing navigation tools, dealing with a dozen video channels, remote controlling almost everything from ashore or afar, networking with the technomadic flotilla, having a robust security system, continuing R&D projects, streaming telemetry to public servers, probing the environment… this is going to take more than a bunch of commercial boxes stashed wherever they fit!

Much of the discussion in this publication is going to be about how we bring this all into one cohesive system.

Brion Toss Gives the Rig a Once-Over

During the 2008 shakedown cruise, we welcomed a wizard aboard… Brion Toss, author of The Rigger’s Apprentice and other excellent references. He had lots of useful advice, and generally gave the rig his imprimatur… but for one detail. A link plate on the jib furler, with no toggle, was “looking very tired.” It was the wrong part anyway, with very little thread engagement to the turnbuckle. When asked when I should fix it, he said, “before you put the sails up again!” We did.

Meet Shacktopus

Basically, what this requires is a central always-on server that presents the boat’s “website” to a local wireless device or any authenticated browser out on the Net… while also providing back-door interfaces via voice I/O and packet radio. This machine maintains a database of points, steadily polling about 15 nodes scattered around the boat (those are the little purple diamonds on the title background image on this PDF).

The nodes are based, for the most part, on the open-source Arduino microprocessor… readily available and cheap, with a very friendly support culture. There are so many people hacking with these now that just about any flavor of I/O can be found off the shelf as “shields,” little daughter boards that piggyback onto the Arduinos themselves.

As this project develops, much of what I’ll be writing in these reports will be about the nodes… each associated with some broad swath of ship operations. In many cases, these do not do any local control, but simply gather system state to allow meaningful graphic displays. Example: 3 diesel tanks and 2 Racor filters makes for 18 possible relationships of source/return/filter. A live block diagram with bright or grayed-out lines will let me see at a glance what’s happening with fuel flow.

The Mega-drawing

There is a poster-sized drawing on the wall of my lab (6 sheets of paper), representing the whole ship system as currently conceived. Here are the regions, from upper-left to lower-right… click image for the full-size version:

From left to right, top to bottom:

1. Computers and networking, with the Linux board, Mac Mini, USB hierarchy, speech I/O, data-type-agnostic crossbar matrix, and so on.
2. Communications, including ham radio, datacomm, APRS, and back door.
3. Audio, with the piano and mixer as well as stereo and distribution tools.
4. An orthogonal view of the boat showing the Arduino nodes, all of which talk USB (or XBee, if too far away) back to the system console.
5. Navigation and ship operations, based on standard NMEA 2000 tools… with associated subgroups like autopilot and outside helm console. This separate network has a gateway to my own server so all the ship sensors are available.
6. Power management, including Outback inverter-charger and solar controller with its own monitoring system… also streaming into the ship server.

I don’t yet know the total number of data points (both “real” and “derived”), but it’s over 250. Each of these is added regularly to a back-end database, with time stamps… making it possible to generate historical plots for any measurement or correlate anomalous events to assist in fault detection.

And speaking of fuel…

Fuel Monitoring with NMEA-2000

Meet Jeb

I’m sure I don’t have to work to convince you that having a way to monitor the fuel in your boat’s tanks is a Good Thing… suddenly running out can turn a fun day on the water into an unwelcome lee shore adventure. If you’re burning diesel, it’s important to avoid sucking air, as it will then be necessary to bleed the system.

Even without considering emergencies, you probably want more than a gross approximation of the amount remaining in your tanks. This data is essential to develop a fuel curve for the vessel, allowing you to find the most efficient cruising speed and increase the accuracy of range predictions in varying conditions (though you’ll get better data by directly measuring consumption).

Before getting into our tank monitoring system, I have to share a little tale from the 1970s. I had a small business in Louisville, and paid a fellow to come around every couple of weeks and do the grown-up accounting stuff that mystified me. Tom had many other clients, one of which was a coal company in Eastern Kentucky.

He showed up one day, laughing, and told me of his recent visit to the hills. The owner had told him that he reckoned someone was stealing diesel fuel from the tank at the barge dock, since there had been some wild fluctuations in its reported level. He was hoping that Tom could figure out the numbers and help find the culprit.

Looking over the purchase and consumption records was making no sense, so Tom decided to begin at the beginning, as they say. He made his way down to the dock and found the attendant, a lanky fellow named Jeb. “Morning,” he said. “We’re having trouble figuring out how much diesel is being used… can you show me how you measure it?”

“Yessir, I sure can.” He picked up a long stick, printed with numbered tick marks. “You see this here stick? I just put ‘er all the way down in the tank, like this… and then when I pull ‘er back out, I look at where it’s wet, ya see? I write that number on the clipboard and take it up to the office.”

Tom peered at the stick. “Which end do you put in the tank first?”

“Shee-it, I dunno!”

We can do better.

Manual Methods

Actually, there’s nothing intrinsically wrong with a stick… my ex’s Cal 2-29 with one-lung Farymann diesel uses this method, and it works fine (she even named the stick “Jeb”). With careful record-keeping, attention to which end goes in first, and basic hygiene, this may be all that’s needed.

One step up from the stick is the venerable sight glass: a piece of clear tubing mounted vertically on the outside of the tank, plumbed into it at both ends. It doesn’t get much simpler than this, and if your tanks are conveniently located and you don’t care about remote monitoring, it’s a time-tested and perfectly acceptable method.

I’ve known people who take a third approach, and have managed to fine-tune it to remarkable accuracy. With careful observation and record-keeping, one can monitor the running time of an engine (especially if it’s kept at a constant cruise RPM) and apply a simple gallons-per-hour formula to determine how much has been used. This requires accurate knowledge of the engine’s fuel curve, along with an understanding of how that varies with hull/prop fouling and sea state.

You can implement a much more refined version of that with accurate flow monitoring using readily available instruments. This is analogous to battery monitoring technology… by recording the exact amount used and paying attention to consistent fill levels, you can always figure out how much you have left. But this can get out of synch with reality if you have multiple consumers, like a diesel heater and genset, or if you are switching among multiple tanks and not taking careful notes.

In the case of Nomadness, there are three tanks: one of about 90 gallons under the berth in the aft cabin, and two “wing tanks” of about 70 each that are hard to reach beneath galley and pilothouse furniture.

Out with the Old…

The boat came with a clunky system, with an analog gauge on the instrument panel. This was an old meter reminiscent of a 1957 Chevy, and was made worse by the tank-selection protocol: mash one of three heavy chrome buttons to connect the associated swing-arm tank sender to the meter, displaying the fuel level.

These old senders are evil — just wire-wound rheostats (33-240Ω) with a wiper attached to a float on a swing arm. They are famous for failing, as mine had, with the measurement being so random that I longed to get Jeb involved. That wasn’t possible, of course, due to the locations of the tanks.

Wema Sensors

After considerable research, I decided that the new sensors should be from Wema. Mine are the SSS/SSL series, which have the same resistance range as the old standard but operate, magically, with a floating collar that glides loosely up and down a 316 stainless column. I played Jeb a few times to get accurate measurement of my tank depths, then placed the order.

They’re quite beautiful, industrial-strength devices, and were not difficult to install. My wing tanks already had aluminum inspection ports, and drilling the center hole and bolt circle was a quick drill-press job. The aft tank already had the same industry-standard hole pattern, and merely involved some cleanup, re-tapping, removal of old form-a-gasket, and a couple of attempts to get it sealed (re-doing old stuff is always harder than new stuff!).

Maretron TLA-100 Interfaces

OK, so now we have the raw analog data source… how does it make it to a display?  The new marine networking standard is NMEA 2000 (or N2K in boatnerdspeak), which is built electrically atop CANbus. I had already installed a backbone for the autopilot and other nav goodness, so the obvious plan here was to get the Wema sensors on the bus.

Maretron makes a wonderful (though not particularly cheap) line of NMEA 2000 devices, and their TLA100 is designed to convert any standard resistive sender to a stream of events that allow one to see fuel levels on any display aboard the ship. In the long run, Nomadness will have her N2K data bridged to an always-on server that will allow seeing it all in a browser environment, but at the moment I just have a single DSM250 from Maretron at the inside helm.

The TLA100 is configurable, of course; from the display, you can associate each one with a tank number, set capacity, specify gauge resistance, tweak the calibration, or even define a bunch of data points while filling to map the values onto an odd-shaped tank. I should do this, but am always too stressed while at the fuel dock…

Anyway, in the middle photo you can see one of my three TLA100s plugged into the bus behind the helm console.

Virtual Gauges

Now that fuel data is streaming onto the N2K backbone, what do we do with it? This depends quite a bit on the available display, and in some cases it might be just a numerical value… or a window in a multifunction chartplotter display at the helm.

In my case, the excellent Maretron DSM250 provided an opportunity to put all three tanks logically on one screen. The largest tank is aft (at the bottom); port and starboard wing tanks are slightly smaller (top).  At a glance, I can get a good sense of my fuel situation:

Would I do this again, in retrospect? Probably yes, given interoperability with other equipment including a display at the outside helm. But the Bluesea Vessel Systems Monitor (new version here) is much cheaper and can present an amazing amount of information. Ahhh, so many ways to spend boat bucks!

A Word on Complexity

I have often, not surprisingly, had to endure criticism from people who feel that I am over-complicating things. This goes all the way back to the bike epoch, when every few months in the midst of all the fan mail there would be a hostile letter with comments like: “you are bastardizing the simple, beautiful act of bicycling.”

These days, such criticism is more likely to come from sailing purists, for indeed there is a very well-known phenomenon on boats: complicated stuff breaks. Just ask any long-distance voyager about their refrigeration system.

I do find some of those comments ironic, though… with the exception of pure traditional wooden-boat sailing, almost everyone on the water these days is carrying a fairly substantial collection of high-tech tools: internet access, smart phones, radar, GPS chartplotters, sonar, weather sensors, satellite radio, TV, MP3 player, sine wave inverter/chargers, solar panels, and engine monitoring systems. When such folks look at my gizmological overlays and call them “too complicated,” I do have to chuckle a bit.

The whole point here is a reduction of complexity… at least from the perspective of day-to-day operation. If instead all this stuff adds to the confusion and creates more maintenance headaches, then I will have failed.

The real point of this project is to achieve the sort of smooth layering of technology that was well depicted (fictionally) in the Star Trek Next Generation series. Huge sensor arrays and complex systems were reduced to voice interaction and clear graphics, and the whole operation was paperless. The underlying complexity did not go away; it just didn’t nag the user with the need to be cognizant of every little detail. Like my fuel example earlier, something as trivial as a few magnetic reed switches on the tailpieces of rarely seen valves down in the engine room translates into a clear vision of what’s going on in real time.

The key point here is that I am not handing over control to a bunch of microprocessors… at least, not where anything critical is involved. I would never trust a network of computers enough to make it my only way to turn on the navigation lights, for example, but if I throw the toggle switch on the power console and a synthesized voice informs me that the stern light is not drawing current, then the machines are doing their job. If integration of water flow causes a counter in an Arduino to roll over 5000 gallons, prompting it to send a flag to a database-backed server that then includes a service advisory in my morning report, then I will have created a useful work-around for my own inadequacy regarding preventive maintenance.

The Importance of Passion

But there’s a less-pragmatic component to this, and to be honest, that’s what truly drives me. This is not just a toolset, but a way to fold all my technopassions into a single immersive lifestyle. Fellow geeks totally get this, but traditionalists look at all the projects and go, “whoaaaa, dude, are you nuts?”

As I wrote in my Gonzo Engineering essay, “our motives are usually as guileless as passion itself:  chasing daydreams, building tools, realizing obsessions, shattering limits, publishing, earning grins of appreciation from the cognoscenti and accolades from neophytes.” In other words, it’s fun.

There’s nothing radical about combining one’s interests with travel; mine just happen to be übergeeky. The sailor who paints the scenery while anchored in a beautiful cove is pushing exactly the same set of buttons.