Note: My Shacktopus neologism has had three meanings. The first one was designed in 2005… a sort of paleo-smart phone of backpack scale, bringing lots of resources into a single system for substrate-independent technomadics… I called it a “communications laptop.” The second use of the term was never well-defined, and was a temporary name for the distributed data collection system aboard Nomadness. And the third one happened in 2015… a multi-functional power system built into a collapsible hand truck. Sorry for the confusion!
Work trip #3 was a short one, aborted by bad weather and flagging motivation. I showed up after dark with big companionway-hacking plans for the next day, hauled my table saw to the dock and covered it with plastic to keep condensation at bay, stayed up late faffing around online, then woke pre-dawn to a full gale with the Bosch threatening to take a flying leap into the drink. I lashed ‘er down and tried to get back to sleep, but no luck. It rained all day, and the enormity of the whole project weighed on me until I shrugged and made the hour and half commute back home.
Sometimes that’s just the way it goes.
Indeed, the hardest part of this is keeping a vision of the recent teaser voyage in the foreground of my consciousness whilst grappling with a lab full of poignant dusty reminders of projects unfinished, short cold days of a northwest winter, and winter moorage so far away that going to the boat is an event.
What this means in practice is that I have to take a modular approach, working on subsystems in the lab and then hauling them aboard to deal with integration. That’s necessary anyway, given the minimal shop facilities on the boat, but it adds another layer of synchronization if I am to avoid surprises. There are three major modules in progress: communication console, outside helm nav station, and the waterworks.
Feeding the Tanks
As usual, it started simply. Last week, I took the Katadyn 40E watermaker to the boat in order to confirm the mounting location… assuming that it would just go in the big hole where the old one came out. It did fit easily, but I wasn’t happy about the thought of servicing salt-water prefilters in the same equipment bay that includes the 115-volt AC breaker panel, so looked instead at the space under the galley sink. That could work, though it would be an awkward three-dimensional puzzle to install and will be very uncomfortable if I ever need to remove the electric pump and operate it manually due to a failed power system (one of my main reasons for choosing that model).
Right on the other side of the wall, however, is the aft head compartment, where the decommissioned Bosch propane-fired demand water heater is still hanging (it is being replaced by an Isotemp mounted behind the shower compartment). The available space is on the order of 24 by 34 inches, with a good 3-4 inches of depth before it would start to become annoying while interacting with the Lavac. Hmmm.
Suddenly the water-processing system snapped into focus. The reverse-osmosis watermaker and its prefilter will go there… along with a Water Fixer ultraviolet purification system. The old Bosch exhaust opening will carry a dock-water fitting and entry point for jugs or rainwater, and a system of valves will allow cleaning the water enroute to the tanks, or from the tanks on the way to the spigots around the boat. It will even support “water polishing” as I do with the diesel fuel (pumping from one tank to another through a Racor filter), and four channels of total dissolved solids monitoring will give me a quick look at watermaker output, ship pressure water, incoming dock water, and the super-clean stuff after the point-of-use filter at the drinking tap.
In the time-honored tradition of creeping featuritis, this continued to grow until it reached absurdity, then was pruned by the usual techniques of factoring, sanity-checking, and tossing out superfluities. It now includes a (locked) valve to permit slurping in raw water when I’m in river systems, a high-silt booster pump and prefilter for dirty brine, a way to route filtered dock pressure water directly to taps instead of into the tanks, and various other features. Naturally, the biggest design challenge is making sure that the user interface (14 valves) is clear enough to make sense some spring day five years from now when something is amiss and I have not just spent hours staring at plumbing diagrams.
This has to be self-documenting, so a hinged cover panel will carry a big clear graphic that makes it obvious what’s going on. More webness to come on this topic as it develops.
I’ve dusted off the old equipment box from Bubba-the-kayak, and am installing the Yaesu FT-817ND ham rig and the NUE-PSK modem. This already has 24 amp-hours of battery, sealed connectors, a dedicated 30-watt solar panel with charger, and related goodies… so in the salty Nomadness context this will likely become part of the new Shacktopus system (or at least a dedicated field radio station independent of the rigs built into the ship).
Shacktopus began as a sort of “communications laptop” that was under intensive development here in 2005 until my dad passed away and necessitated a 6-month expedition to shut down the old homestead in Kentucky. A small Linux board and a lightweight micro presented a webbish interface to a rather large suite of tools, including radio front end and a variety of sensors… and it could be accessed via a handheld radio using DTMF commands and synthesized voice response as well as a PDA or laptop. Reminiscent of the BEHEMOTH and Microship projects, audio and serial routing allowed all devices to appear as a single, simple user interface… here’s the drawing, although the system was never completed:
I no longer need a backpack rig like that, but the design problem on Nomadness is very similar: lots of diverse capability that has to be accessible from a variety of places with a minimum of hardware. Since a lot of engineering went in to Shacktopus, I’ve been thinking quite a bit lately about how to dovetail it into the new ship while keeping the boundaries clear enough to allow product spin-off down the road. The key, as usual, is modular design.
The basic problem is familiar to almost any radio geek: lots of rigs and gadgets, all with their own ideas about power, speakers, microphones, operating procedures, and front panels. The result is usually a sprawling “ham shack” with dangling mikes, a snarl of cables, custom switch boxes and patch panels to multiplex scarce resources, an overall
feeling of clutter, and a high likelihood of pilot error.
In a mobile environment, this is simply unacceptable… yet even here in 2008 there is no standard “bus” along the lines of NMEA 2000 that can tie radio modules into a single integrated environment. Most modern rigs do have computer-control capability… and there is even a comprehensive set of API tools called hamlib that creates a layer of abstraction between vendor-specific stuff and the broad concepts of radio operation. In Shacktopus, this is carried much further, incorporating Wi-Fi, local environmental and security sensors, mode-specific tools like PSK-31, location-aware applications, graceful adaptation to available network resources, power management, and so on… exactly what I want on the boat.
So the upshot of all this is that it has finally become clear how the Shacktopus concept maps onto the Nomadness project. Everything on the ship needs to be accessible at multiple levels: local dead-simple interface that works when the geeky stuff is broken or unfinished, web-accessible toolset that can be reached within the LAN or (more slowly) from afar, voice interface that can allow at least some functionality from any hand-held radio, and a clean local operating console that hides as much complexity as possible while encouraging application-specific activity. The waterworks mentioned above is a good example of the latter: associated with my drawing of the system is a chart that relates each operating mode to a set of valve positions (open, closed, or don’t-care). I don’t want to have to figure that out every time, for therein lies madness; the user interface needs to be modal and remotable, yet open enough to allow hacks and work-arounds when something goes awry.
Somewhere under all this is a sailboat, of course, and I haven’t forgotten that. Old salts roll their eyes at this apparently gratuitous geekery and remind me that simple is always better on a boat.
Believe it or not, I agree completely.
The basic premise of this whole project is not the addition of complexity… that would be a failure. Instead, it is a layering of tools to maintain the simplicity of a sailing vessel while adding a range of useful capabilities that would normally be considered impossible in such a context. If that can be done without cluttering the experience with constant tinkering, then we will have succeeded.
You must log in to post a comment.