Intertwined Fronts, Stereo, and the Microship

Cold, dark winter days are demotivating and I didn't get it together to go see how the boat handles a foot of snow loading, but I am happy to report progress on three simultaneous fronts: the ship's Shacktopus network, the Boat Hacking book, and an online store to conjure a nickel generator from the first two.

I have been writing in the exquisitely agile Scrivener environment that allows me to see the whole book project in parallel, at any level of granularity... yet encourages drilling in at any point to write (with a full-screen mode to hide the cluttered desktop, or a split-screen mode to deal with reference material). What is fun about this is the way the book has become a live development document that drives the ship system design. I theorized that this might work, but during the first few weeks of doing it in Apple's Pages, I found the process cumbersome, sequential, and very layout-oriented. Scrivener has fixed that, providing a context for big-picture brainstorming with smooth transition into finished text at any point. If you are contemplating a book, you owe it to yourself to check this out; it was written by an author because it was sorely needed, and the price is completely sane ($40). If I didn't already use a Mac, I'd probably get one just to run this and OmniFocus, which have quickly become indispensable tools around here.


Anyway, the book is now 10,671 words along and taking shape nicely, with all the chapters on virtual index cards pinned to a corkboard. After a few dozen pages of context-setting, there is a chapter called the "Node Catalogue" with one section for every Arduino or other widget hanging off the USB hierarchy. This was intended as a clear way to explain the system to readers, but I have been amazed to discover that it is an even clearer way to explain it to myself. The design has thus been stabilizing dramatically (complete with cruft-reduction and modular task definition, which is the only way to keep it real). I've already begun the first simple node (Sewage), as well as the initial process in the hub that scans all nodes to deliver queued messages and build a table of data points. This in turn has subscribers in the form of the Datawake archivist, security/watch software, and web server.

If things continue in this vein, I might actually have a book ready shortly after the system is buttoned up. That would be a first.

While all this has been going on, I have been working on the online store... and have started lining up dealerships, selected the shopping cart software, and planned the overall organization. It should go online in embryonic form sometime in the next couple of months, and I'm looking forward to it; at the age of 21, I cut my business teeth back in Louisville with a mail-order electronic parts business called Cybertronic Systems, and have missed it ever since. The plan, of course, is for this to provide another cash-flow generator to help justify a competent full-time home-base manager.

Console Integration

I haven't started fabrication of the ship's nerve center yet, but it is fairly well defined. A corkboard (the real kind this time) is on my lab wall with an actual-size console delineated with yarn and pins. Manila folder cut-outs show all the equipment front panels, and I can move them around with push pins. It's crude, by CAD standards, but having a full-scale mockup has always been most useful to me at this stage, since I can feel it.

The console is 40" wide and 15" tall, and it opens fully for access: the enclosure rolls forward on embedded rubber wheels, the front panel hinges down, and the top panel flops forward onto the same plane. This exposes all the microprocessors, interface hardware, and other goodies, opening it up onto a single 40x45-inch surface that is workbench height at the boat's original nav station.

As with BEHEMOTH and Microship before, I suspect the biggest single engineering problem will be radi0-frequency interference (RFI)... computers and radios really don't like each other very much, and this system has dozens of each. This is a very good reason to start bringing subsystems online the moment they are installed, rather than waiting until all the packaging is done to invoke the smoke test and listen to the chorus of birdies from DC to daylight.

The Ship Stereo

It seemed at first a bit of an extravagance, but I bought the only marine stereo I could find that met all the desired specifications... you can click this little photo for a new window with product information about the Fusion MS-IP500:

This thing is amazing. The iPod docks inside a waterproof compartment, with its complete user interface brought out to the front panel and integrated with the stereo's own controls. It accepts a black-box Sirius satellite tuner, has line level inputs (and outputs for all zones), uses a class-D amplifier that wastes much less power, and even has a CANbus interface for the zone remotes. With my iPod classic tucked inside, this thing has more hard drive space than my laptop (and sounds spectacular)!


Somebody finally got marine stereo right, and I look forward to getting rid of the existing CD widget with gratuitously blinky front panel, non-intuitive interface, and the Radio Shack speaker selector switch box whose guts are dangling into the power distribution bay (which is itself about to get a major makeover with Outback gear next month).

Of course, my choice of the Fusion was no accident, nor was my choosing this moment to fiddle with it. This is the audio amp for all sources on the boat, not just music... and it will mount next to the Edirol M-16DX mixer as well as the sparse-matrix audio crossbar that is a distant relative to the rather grand 32x32 Auxbar we built for the Microship. I still haven't completely ruled that out, since it works so well, but I need a manual mixer for interactive tasks like podcasting and music, and a few channels of software-controlled configuration management are needed when we're in minimal-power configuration. So a board of latching relays next to a serious studio mixer is a nice, er, mix.

Previous Project Update

Speaking of my earlier technomadic contraptions, I have two updates for you.

First, BEHEMOTH is on display in the Computer History Museum as part of their Innovation in the Valley exhibit, and is still entertaining crowds as always. The bike has been enjoying all the attention (even getting loaned to the Williamson Gallery for an exhibit on bicycle art a while back!), but the Microship is still lying at the center of a mountain of lab clutter. Her hull hasn't felt the lappings of salt water since 2001, and this has been bothering me more and more.

It has been difficult to accept that after a decade of my life devoted to this project (along with all available resources), the planned 14,000-mile Clueless and Lark expedition will probably never happen. I have some rather serious back problems, not to mention other creakiness, and, ironically, an 18-ton steel ship is much more realistic for my future wanderings than an athletic little machine. But with all the focus on Nomadness, I wince every time I step around Wordplay... still poised for adventure in the Microship lab, awaiting her technomadic destiny.

It has thus become evident that she should probably find a new pilot, someone who is mediagenic, geeky, and insanely adventurous. I would expect to spend at least a full-time week or two with the skipper here in my lab, sharing all aspects of the design as well as the infrastructure it represents for an overlay of systems, and I'll also stay available for brainstorming and consultation as the new project develops. The boat sails like a dream (some heavy-hitter marine architecture consultants were on the design team), and is the resultant of over a dozen man-years of focused engineering work. This is a powerful substrate for a high-profile expedition, and that really needs to happen.


She won't be cheap compared to other boats of this scale, and she's certainly not for everyone. But for the right person, she could represent a huge shortcut in time and money compared to the R&D project that would be required to replicate this range of capabilities: pedal, electric, and sail propulsion; amphibian mode including folding akas and retractable landing gear; 480-watt solar integration; hydraulic controls; and much more.

I can help the new skipper brainstorm the "business model" of a Microship expedition to see if it might benefit from sponsorship, publishing deals, or other spin-offs. Of course, she can just be a high-tech nautical toy for one with deep pockets and a yen for engineering. But personally, I would prefer to see the boat achieve her originally intended purpose of an extended public journey through coastal and inland waterways, and for the right person there is a good probability of corporate and media support (given the continuity of my work over the past 25 years).

I am not mentioning any price tag because it depends on how much is included and the extent my own ongoing involvement, and there are some alternatives to outright purchase that involve more of a shared project. (If you're just looking for a low-cost one-person trimaran, this isn't it... you might want to consider the Hobie Adventure Island or the WindRider, both of which are excellent.)

There's a photo album over here if you want to look her over. Serious inquiries only, please.

Yearnings

I knew this winter was going to be hard; sometimes working on the boat from a distance is maddeningly abstract. The waterworks panel is still on the bench, awaiting one more trip to the ship to return with real numbers, and little scraps of paper remind me of stuff to take or pick up. The new electronics lab will be a great "ship simulator," but in a way it adds yet another level of indirection: mechanical assembly down in the shop, electronics and software design upstairs, the boat impossibly far away.

Was this really just a few months ago?


I'm ready to get back on the water.

Fair winter winds,
Steve

Wintry Notes from the Nomadhouse

I've never been much of a fan of Christmas, except perhaps when I was a kidlet in the nuclear family of mom/dad/me back in Kentucky, long ago and very far away from other relatives. Back then, the tree glittered and new toys appeared, just as they should (nothing has really changed).


Tinkertoys, trains, erector sets, the usual boring clothes and such... I was easy to please back then, and wasn't particularly aware of the lack of a big family network. I only met distant grandparents once or twice... they all died off before I was a teenager, and the news of their passing was somewhat indistinct and hard for me to visualize. Slowly learning of the family though the artifacts that have landed in my life, I deeply regret this; some of them were amazing people who had a lasting impact on their communities.

Now my parents are gone as well, and but for a recent delightful correspondence with my newly email-savvy 90-ish aunt, I have almost no ties to family history. Perhaps it's the reminders of mortality that crop up now and then (or maybe just the Seasonal Affective Disorder that's endemic in the Northwest), but this has recently started bothering me. It is weirdly disturbing being "the end of the line," though it does make letting go of things via eBay much easier. It's actually a relief when something leaves... one less thing to clutter the mental database, one less thing to have to deal with someday. Or bequest.

The timeline of life is one of cusps and subjective distortion. I played with this graphically the other day, using an online morphing tool to blend two images of my face... one a few weeks ago aboard Nomadness, the other in 1971 when I was in the Air Force (itself a surreal notion):



The image is weirdly oldyoung, which is exactly how I feel at the moment — tinkering with blinky gizmology for a Grand Boat Trek whilst muttering over the compounding manifestations of incipient oldfartdom. Memory of the space between those two images... my entire adult life... is anything but linear, and the morph is a good metaphor for the crazy tangle of overlaid passions and realities that have carried me somewhat randomly to this point.

There are linear clues, I suppose, but really, much of what makes up a life is the perception of phases delineated by epochs of love, place, travel, and work. And the relationship between those things and the calendar is rarely a 1:1 correspondence.

In my admittedly strange case, I look back at four years in a suburban house in Columbus (1979 to 1983). It seemed interminable at the time; I was a homeowner — married and employed for a while, then freelance writing full-time. Three books fell out of that era, including a Prentice-Hall textbook; so did a few dozen magazine articles and even a year of consulting writing for a corporate client in the industrial-control game. And yet, I remember it as a brief blip in my life, a strange interlude between a somewhat languid proto-geek youth and the quirky "career" of technomadics that followed.

In other words, while it was happening it seemed to drag, but in retrospect it appears fleeting.

The next four years encompassed something entirely different: 16,000 of the 17,000 miles I pedaled around the US on my computerized recumbent bicycle... the Winnebiko and Winnebiko II versions (complete with their construction, and a book about the adventure). This is kind of insane, when I think about it... those four years flew by in the youthful exuberance of romantic adventure, responsibility the furthest thing from my mind. But in retrospect, they appear huge, a disproportionately large percentage of my life.

The difference here lies in the anchor points. If I look at my lifeline as a long winding highway, Columbus was the 4-year space between two intersections; the technomadic adventure, though also 4 years, involved thousands of them. Trying to sense them as an 8-year continuous thread actually makes me chortle, so absurd it seems.

And it got crazier from there, by far... but you get the idea. The secret of life extension is the richness of change, yet if you have only change, you miss the sweet continuity of family. And that is something I regret.

Snowbound in the Lab

This maudlin poignancy probably has something to do with having been snowed in for a week, and with today's difficult experience of helping Sky through the last day of Lily, her much-loved 15-year-old Corgi. Please read her beautiful tribute to the little friend who has been a huge part of her life... that last tearful nod to the vet was the hardest thing Sky has ever done.

And of course we've been talking much of life, critters, and change... while the woodstove creaks, the wind howls outside, the lab roof groans under a foot of wet snow, and the boat's webcam shows a bouncing wintry harbor scene. But we eat and love well, here in our isolated little world, and visitors wander by now and again to brighten the moment. (photo by Sky Myers)


Despite everything, boat progress has been steady. All the waterworks components are in house and about to be mounted on their plywood substrate, the network design is continuing to stabilize, and — perhaps most significantly — I have cleared the clog of dormant clutter that was my electronics lab and set it up to be the "ship simulator" for this project. Packaging and fabrication will happen downstairs in the lab, which is now reasonably habitable thanks to recent insulation and other improvements; microprocessor tinkering and software design will occur upstairs (where it's warm enough for delicate surface-mount soldering and hours of keytapping).

Here's the Nomadness R&D facility:


The building is 10 years old now, originally constructed with the idea of quickly banging out a couple of Microships. I am still trying to figure out what to do with Wordplay... last night, needing a stable low-impedance 12-volt power supply for the lab, I contemplated crawling into the hull to cannibalize the deep-cycle battery (pic) and its charger. That's how it starts, and the realization was not without a few pangs.

The plan with this "simulator" setup is to provide a generous workspace around the console system, which includes the Shacktopus hub along with all the communication and audio gear. The dozen or so Arduino nodes, wirelessly linked by Xbee, will be cobbled together on the bench using Eagle and doubtless a few kluge boards, programmed using the Mac, linked to the hub, then deployed here and there with as many sensors as possible to create a realistic environment. The comm systems will involve coding as well, so I get the feeling I'll be spending quite a bit of time developing (and writing about) this system.

Nautical Gothic

Of course, what this is really all about, though somewhat hard to imagine at the moment for all the reasons above, is getting back Out There. I'll close with this photo of us by my dear friend and piano teacher, Bonnie MacPhail:


Happy New Year, my friends....

Steve

The Route through the Canal

This freezing week has been a time for system design work, the start of a new book, waterworks fabrication, and preparing my office for use as a ship simulator during the software-development phase. We did make one brief run to the boat last week, then got stuck in a nasty snowstorm enroute back... which turned the normal 1.5-hour drive into 3.5 hours. I discovered that NEWT, my Dodge RAM 2500, is very nearly the worst vehicle on the road when it comes to performance on icy roads.

As I crept painfully up hills at an angle of about 30° (averaging the crown angle and the grade), wheels spinning at the precise speed necessary to melt just enough to gain traction but not so much to spin beyond that, other cars and trucks of all descriptions easily cruised past. This happened on two long hills, and I was not impressed. I've driven in snow all my life, and this was just weird... probably the result of too little weight in the rear. The truck is supremely comfortable, but ya'd think, for that kinda money, it would stick to the road better.

Oh well, at least we didn't end up in the ditch, or worse. On to the fun stuff!

Waterworks Update

I've laid out the watermaker and UV filter system on an actual-size template of the panel that will be mounted to the bulkhead in the aft head compartment. For a while there was some doubt about making everything fit, given the constraints: horizontal RO membrane, placement of the prefilter below everything else so service doesn't splash salt water on powered components, hose routing out to the rest of the boat, general serviceability. The trickiest bit was the configuration of the valve system.

Here is part of it, still in rough tinkertoy form:


I'll describe this in much more detail when it's actually done, but basically the water out of the UV filter assembly enters at the upper left, and the valve to the right of that enables output to a local faucet as well as the pressure line to the rest of the boat. Heading down on the left side are two stopcocks to select filling port or starboard tanks; to their right are two more that do the same for reverse-osmosis product water. And the little 3-way in the middle is to select whether the latter is piped to a local beaker for testing, or into the system (with total dissolved solids metering).

This has been fun to lay out, and when it is done will allow pretty much any combination of features imaginable given the general mix of resources: pressure-regulated dock water, domestic pressure system, PowerSurvivor 40E Watermaker for converting salt to fresh, Water Fixer UV filter to render the dirty clean, two 45-gallon tanks, gravity feed rainwater collection, and quality/flow analysis. I can fill the tanks traditionally from the deck fills, use pressure water that is prefiltered, and even "polish" water as I do the fuel... pumping from one tank to the other through the filter system. A flow meter and pressure gauge will provide quick visual indication of activity, though at the moment the instrumentation is eyeball only (not interfaced to the ship network).

Shipnet Update

Speaking of which, the boat's "nervous system" is getting closer to reality. I've been playing with an Arduino board via a laptop USB port, and three more are arriving this week along with some prototyping shields (daughter boards that expand I/O and provide a little prototyping space). The architecture drawing is actually looking rather stable, with 13 nodes scattered from bow to stern.

Part of the design that held me up for a few days involved the pesky always on requirement for all this, a constraint that made me turn back (with great reluctance) from the idea of using a Mac Mini here. It would definitely be my embedded platform of choice, but it slurps 15-20 watts when idling... tiny compared to a desktop, but still nearly 50 amp-hours per day from the perspective of my 12-volt power system. "But hey," I thought, "why not keep the Mac and let it sleep much of the time, using a little embedded board to poll nodes, watch for alarms, and accept connections from the back-door comm channels?"

This launched me into an entertaining flurry of design drawings that ultimately resulted in a separate hub system, quite capable in its own right, multitasking vigorously and maintaining a little database of points. Ooohhhhh...

Oh, wait. That is the whole point of the central server. Having a little one just doing part of the job for power-management reasons introduces all sorts of modal ugliness when the Big Iron comes and goes, not to mention design complexity, synchronization whenever the map changes, and other cruft-fodder.

So we're now back to a streamlined system, with only one low-power "helper" adjacent to the Hub. Like all the nodes, it is an Arduino... and one of its jobs is to allow me to reach in through the back door and give the main machine a THWACK if necessary.

Actually, the back door is one of the most fun parts of the boat. The theory here is that the main pipe to the world might not be 100% reliable: that's a lot to ask of an EVDO router with cellular connection and fail-over to opportunistic WiFi, an Ethernet hub, and a Linux box with a lot of custom code. I will hopefully be spending a lot of time in the boonies, and besides, I may not always have a laptop and net connection handy... so there are three other ways to interact with the ship from afar.

• First, another ethernet pipe, using a WIZnet or XPort module piggybacked on the little Arduino board. If the server isn't responding but I am getting in to the ship, I can connect to a terminal session on this widget, check for alarms, then stretch a languid electronic finger out to push the reset button on the Big Iron.
• More in the vanilla zone, a terminal session will be avaiable via packet radio, probably using the venerable Yaesu 290 and the Kantronics KPC-3+ terminal node controller. The beauty of this is that when not explicitly configured for packet use, it doubles as an efficient 25-watt APRS tracker, which I originally used on Bubba the kayak. Already in-house and done... that's an interesting twist.
  
• The most common back-door connection will probably be DTMF (touch-tone) commands from the submersible Yaesu VX-6R that is always in my belt pack. This doesn't allow a very verbose command set, but it's good enough... an MT8870 decoder chip is owned by the Arduino, and a little monitor program will parse my short numeric sequences and respond by sending serial strings to a V-Stamp text-to-speech board whilst yanking the push-to-talk line of the Yaesu 790 (twin to the above, and sharing a dual-band whip via a duplexer). Naturally, the boat can also initiate contact, calling me if something requires the skipper's attention. On the UHF ham bands, such "auxiliary operation" is legal with proper ID and non-commercial intent.

I'm also looking at a minimal LCD/touch user interface at the console, but that may prove to be superfluous if the hacked-netbook idea proves successful.

It's still a bit early to go into much more detail; I have a bad habit of publishing lots of specifics of things before they are built, thus propagating eternally googlable data that is dead wrong. So I'll resist the temptation to prattle on about the pretty pictures spread out before me on the desk, other than to list the current crop of nodes by title only:

• Water
• Companionway
• Galley
• Helm
• Arch
• Dinghy
• Midship
• Engine
• Sewage
• Bow
• Communications
• Power
• Monitor

Each of these has a small cluster of local sensors, and together they serve as a distributed data concentrator to minimize the snarl of cabling and poor noise-immunity that would otherwise result from a centralized system. Some also have output capability where useful, in a few cases even running local control tasks.

One of the primary jobs of the Hub is to continually inhale all this and maintain a current table of values which are then available to the web server, monitor tasks, archiving/graphing software, and so on. It should be no big deal to do something like browse to the boat (whether aboard or not), check the main status page, notice that the fridge is a little warm, plot the last week of temperatures, add markers for all the opening events, correlate that graph with power and ambient temperature for the same period, confirm that the water pump for the heat exchanger has been cycling, and decide whether something really needs to be fixed or if I just bumped the thermostat that time I clumsily returned a bag of carrots to the drop-in. All that should only take about as long as it did to type and edit this paragraph.

Indeed, the key to all this is improving the ease, comfort, and quality of life aboard. If it's not fun... if it imposes complexity that gets in the way of enjoying the voyaging life... then I'm doing something wrong. There is a long-recognized truism about the virtue of simplicity on boats, and at first blush this might seem a wild excursion in the opposite direction.

But if, as intended, the details fade into the background and my "situation awareness" grows to encompass parts of the ship that are normally only noticed in crisis-management mode, then we will ll have created something sweet. Which brings me to...

Boat Hacking

I've written 5 books over the years (6 if you count one that is still only available as a PDF, though Lulu calls), and every time I do it I swear I'll never do it again. I've dealt with the absolute nadir of publisher ethics and am still owed money for ancient royalties on Computing Across America, I've been orphaned (twice!) by editorial musical chairs at Big Famous Houses, I've hired and fired an agent who covered his own ass when I had legal trouble with a New York publisher, and I've self-published with visions of grandeur... only to see just another nickel-generator. It's not easy, and each one takes many months of work.

I've also had a few that were stillborn. One that makes me wince even after 17 years was the BEHEMOTH book, lovingly outlined in a fine-print 2-page spread stapled into the Journal of High-Tech Nomadness back in the early '90s. Geeks and fans were pre-ordering copies, and "Real Soon Now," honest, I was going to stop traveling and dig back through 3.5 years of sketchy notebooks and heavily edited schematics to explain every part of the celebrated bicycle in a playful-yet-thorough fashion. Really.

I don't think I ever even wrote one page. I ended up sending folks collections of printed monographs and other material to compensate for their deposits (and refunding a few).

The problem, of course, is that documentation is hard enough without trying to go back later and make it sufficiently exuberant to hold its own as a book. It should have been done while the bike was under construction... I certainly had the time, and it would have sold well.

I still had not learned the lesson during the Microship era, though I did publish about 140 status reports, plenty of stand-alone articles, and a couple of design documents. The direction kept changing, geeky bits conjured in the early years were obsolete by the time we were slinging epoxy, and motivation faltered as relationship-demise doldrums struck in 2002. Again, no book, although I did begin one that segued into the Gonzo Engineering theme before becoming sidelined by the aforementioned musical chairs.

It's a jungle out there.

But I think I have it figured out now. As I'm building all these systems, I need good documentation anyway... and it's not too big a leap to make it read well (I used to do that form of "consulting writing" for corporate clients anyway, translating mind-numbing engineering text into something interesting for clients to read). If I write about the components while they are fresh in my mind, including complete hardware and software designs... then there is plenty of material.

Upon reflection, I realized that this is my niche. The boat-book marketplace is already well-served by experts in engines, electrical systems, navigation, and every other nautical topic imaginable. But I have yet to see one on Boat Hacking, which is the title of my new book.

Oh, and please don't order a copy just yet! I've learned that lesson. It is in progress, though, about 25 pages along, and sample chapters will appear occasionally on the Nomadness web site. In fact, there is an easy one over there right now.

The Root Canal

If you were wondering what any of this has to do with the obscure title of this post... well, I had gutta-percha installed in a tooth today, retrofitted under a crown that didn't magically make the persistent pain go away. Here's the result, snapped on the sly during the clean-up phase:


It was not much fun at all and I sometimes really hate being biological, although the iPod and nitrous certainly helped. (I have never been able to transcend dental medication.)

JUST SAY N₂O!

Cheers from the murky zone of throbs and painkillers...
Steve

Shacktopus Architecture

Real physical tasks are queuing up, but it's a rainy holiday weekend and I find myself more engaged in gonzo engineering than rust patrol and plumbing. It began while sketching a simple controller, and suddenly the whole Shacktopus network design became illuminated in my brain... an area that had grown murky, overwhelmed by too many choices over lo, these many years.

But first, some context from one of the nodes...

Brighteye

I have started working on the assembly that bolts onto the very nose of the bow pulpit, adding 6 inches to the overall length of the boat. This module includes a remote-control 3200-lumen HID spotlight, waterproof color camera, IR emitter, a pair of LED navigation lights, a small microcontroller, 3-axis accelerometer, and a sometimes-relevant PIR motion sensor.

Seasoned readers of my perennial technomadic maunderings may recall the video turret, a project we built at UCSD 14 years ago (!) to allow a single camcorder-grade camera to be aimed in any direction with remote zoom and other controls. It turned into quite an ambitious robotic project, as you can see from the photo below: an embedded FORTH board on the Microship multidrop network took care of motion control, complete with a pen-based graphic user interface on a wireless ruggedized Newton that routed commands through the hub. Ahhh, fond memories.



The irony of that machine was that by the time Wordplay was complete enough to consider actually bolting on the turret, cameras had gotten so cheap that it would have been more sensible to scatter a bunch of them around the boat and use the video crossbar to select the source. That's not quite true, since the steerable camera was higher quality than the cheap bullet-cams of the day, but still...

Well, now I have a big ship and the same twisted geek fantasies, so I've been staring again at the turret. I'd really like to use it, but it just doesn't fit the application (although I am tempted to repurpose it by ripping out the video stuff and installing a directional WiFi antenna, using heading from the rate gyro and signal strength data from the router to keep a distant hotspot centered between half-power points).

But I still need cameras around the boat for video production, live webcam, night-watch, and security. At the moment, with Nomadness parked far away in a marina with significant western exposure, I'd really like to be able to check in during windstorms and keep an eye on my docklines (one brand-new Samson Pro-Set 5/8" nylon bow line chafed through one of its 3 strands in the last storm). Besides, there have been recent thefts over there... I have an Axis 210 webcam in the pilothouse, but I want one on the arch staring down at the cockpit as well as a steerable one on the bow that can let me scan the whole area or peer up and down the dock... emailing me if motion-detection software detects change within a defined region while I'm not watching.

Given a steerable sealed camera on the bow, some other capabilities become available... like being able to flip open a laptop and look around from the cozy berth, capture footage of crazy conditions without trying to fiddle with a camcorder while holding on for dear life, and automatically post shots from any angle while traveling. So I am mounting a waterproof Helmet Camera on a high-intensity discharge Golight with wireless remote, then adding an Arduino board linked to the ship's server for position feedback, power control, and sensors.

The video will be piped through an IP camera server, and a little web app will allow control of the light and camera from a browser. If the camera turns out to be sufficiently IR sensitive, I'll add an emitter for night use; there are port bits left over and plenty of power available, so this thing can grow as needed.

This reflects the fundamental paradigm that has driven most of my projects over the years: leveraging existing good engineering by blending slightly-hacked products into something larger. Life is too short for reinventing wheels, and by factoring an idea into components that map onto off-the-shelf solutions, I can minimize the amount of work necessary to break new ground. The two video turrets are a perfect example: the old one was probably close to a man-year of work; this one will probably be done in a couple of weeks of bench time.

Shacktopus and Datawake Evolution

Names are important, for they create mental "handles" for things. It has thus been frustrating for me to have a rather loose definition of Shacktopus, since it began as a sort of communications laptop, paused for 3 years, then evolved into a more generalized toolset for interacting with a complex mishmash of systems without having to remember the details of every one. I've also been bandying about the Datawake concept, originally hatched as the data collection system that leaves a virtual "wake" of information as the ship moves through time and space (it even had a spinoff a few years ago).

Both of those capabilities are essential to the Nomadness system, and, I would argue, are widely useful. Over the past decade, I have come up with variants on this architecture every time I have had a surge of creativity, a glimpse of new technology, or input from someone with good ideas. The resultant was a bit of a jumble, with a half-dozen microcontroller flavors, something that is always on that serves as a hub, and some kind of server that magically provides a web interface while stuffing things into a database and running small apps for security/watch functions.

Well, now that I'm actually building this, it's time to clear up the ambiguities and get clear on specs, components, protocols, nodes, data types, network tools, and all the rest... beginning with the mapping of linguistic handles onto conceptual subsystems so we can talk about it meaningfully:

Shacktopus is a quirky word that I coined in 2005 (rejecting Winnepacko and Geekpack) to reflect the image of an intelligent multi-armed critter controlling a ham shack... initially conceived as a backpack-scaled QRP station with network access and lots of other tools. There is of course a bit of the maritime imagery here as well, and I am now seeing this as the combination of systems that allows both local and remote interaction with communications, sensing, security, power control, A/V, and other gear. Basically, it is a cushioning layer between the user and a hugely complex mess of stuff. It should never be necessary to drag out manuals in order to operate one's own machines, there's no excuse for a tangle of cables, and a large suite of tools shouldn't come to define one's living space. Think Star Trek (in the later years): the ship has sensors everywhere, and its own distributed intelligence. User interface is smooth and consistent, and unless you are named "Data," you interact with the ship mostly through conversation and occasional finger-tapping on a clean control panel.

Datawake lives in the same overall system environment, but has relatively little to do with humans in its day-to-day operations. It's role is to lay down a detailed history, collecting telemetry from all subsystems, tagging it with time and location, and stuffing it into a database. This becomes useful and interesting in a variety of situations, including environmental observations, failure analysis, security, and power management. Still, it's rather passive compared to Shacktopus — it is the archivist.

Now. What does the hardware look like?

I should preface this with a quick comment on granularity. Occasionally over the years I have built sprawling complex machines, the hardware equivalent of spaghetti code. They were impossible to document, hard to debug, and unless used consistently tended to become confusing over time... in some cases, with front-panel reassignments and extensive back-door kluges. But that was the way things were done back in the day; power supplies and packaging were expensive, so you just crammed everything into one box with a lot of front-panel controls to sort it all out:

Winnebiko II console, circa 1988

Then, in the BEHEMOTH bicycle era, I started using FORTH boards from New Micros. My hardware was still complicated, but I was learning to think differently about code: clear little modules called words, added to the existing ones in a dictionary, with higher-level functions being expressed in terms of lower-level ones in this "extensible" language... usually only a few lines of code each. Over time, I started looking at hardware in the same light, appreciating simple gadgets that do one thing perfectly, with well-defined inputs and outputs and no back doors, side-effects, or shared functions.

Of course, we now have object-oriented programming, which carries this much further (though with more of a "big system" flavor). It's part of our culture, and rightly so. What is less known is that a similar phenomenon has been growing in the world of chips; you can still load up on surface-mount devices and make custom boards, of course, but a number of vendors now offer a very wide range of little gizmos that make complex devices easy to use and hide many of the details. These range from prototype-friendly breakout boards for single chips to low-cost subsystems like USB data-collection modules that would take months to develop.

The difference may be moot at the big-picture level, but what this means is that one can assemble just about anything these days without having to build custom printed circuit boards (unless, of course, volume production requires doing so for cost-minimization).

Aboard Nomadness, this is a lifesaver, and means there should be a fairly short path to initial results.

System Architecture in a Nutshell

So, with all that preface behind us, how does this work? Easy...

One machine will be on all the time, most likely a small Linux box. I'm still considering the Mini-ITX and its variants, but it may be that starting with a finished product made for battery operation is the shortest path to a power-efficient system that works out-of-the-box. I'm looking at the class of subnotebooks called netbooks, many of which ship with Linux and run on the low-power Atom processor from Intel with SSD file storage. Perfect.

Broken in two with the LCD panel-mounted, this yields a net-savvy server with robust tools. A power drain of 2-3 watts I can live with; although I'd love to use a Mac Mini in this role, it's much more power hungry at 20-30 watts (still light compared to desktops, of course, but see the excellent research conducted by AMUG on the subject).

The real lifesaver here that should make development easy is cheap USB stuff. All the interfaces I need (except for an IP video server directly on ethernet) exist in USB flavors, and one big pile of hubs will provide all the connectivity I need for the I/O hardware:

1. Latching relays for configuration management, audio routing as needed for comms (in addition to the console mixer), video routing (about a dozen sources and 6 sinks), and some local power control. (Relays don't switch in sync with the video retrace interval like my old Mitel 88V32-based Vixbar, of course, but for this application, I'll live with the glitch.) My earlier crossbars allowed complete generality; this approach is sparse-matrix but the straight-through connection is signal-agnostic and reconfigurable.
   
2. Digital output bits connected to solid-state relays for power control... standard industrial DIN-rail packaging from Phoenix Contact.
3. Digital input bits (local to the console) for power distribution mapping and other close-in status detection.
4. A bank of retro serial interfaces for RS-232 gadgets like a text-to-speech board, ham radio control ports, a TNC for datacomm, and a bunch of Arduino microcontrollers scattered around the boat. These include a DTMF decoder for remote control via UHF handheld, the light/camera/sensor module on the bow, hatch security sensors, water and air system monitors, bilge water and pump-cycle monitor, cockpit security, remote front-panel interfaces, and so on... possibly even one of the old Auxbar units.
   
5. An XBee radio for the two Arduinos connected by wireless links: dinghy security and an OLED-touchscreen handheld unit (though the latter might be more easily accomplished with an off-the-shelf PDA).
   
6. National Instrument modules for analog/digital/pulse data collection.
7. Maretron USB100 gateway, slurping in all the PGNs in the ship's NMEA 2000 network (rate gyro compass, GPS, derived navigation data, rudder angle, fuel level sensors, engine and fuel flow data, wind speed and direction, depth, outside temperature, power system data).

With one fell swoop and no extra computers, we've just created an environment that accommodates every data type on the boat. Video sources can be switched to a server and viewed in a browser, radios can be reconfigured complete with audio and PTT steering, all data can be collected and stashed in a database-backed website, remote microcontrollers can be queried or mirrored to a terminal window, and (assuming I can figure out the undocumented N2K stream that currently only ships with a Windows client) we can create a multifunction display for the ship nav systems and engine.

And, my favorite part: it's all off-the-shelf parts, most of which are cheap. That translates into incremental development that frequently injects positive feedback to restart the attention-span timer... while still moving me in the same direction for a long time (the key to getting Big Projects done).

While writing this, it occurred to me that I should start posting detailed tech info to the Joomla-based Nomadness site. The split between this blog and that yet-sparce pile of content is along the vague boundary of narrative/noodling and how-to documentation. This isn't the latter quite yet, but pieces are now on order and we should see blinkies very soon.

Cheers...
Steve

Consoling Thoughts

The modular approach to ship system fabrication is starting to manifest itself as little pools of parts in the lab... good thing we resurfaced the crusty old particle-board workbenches a few months ago! The current lab-based projects are:

1. Console (communications gear, audio, geekstuff)
2. Waterworks (fresh-water processing)
3. Bow Module (steerable spotlight/video/sensors & LED navlights)
4. Field Radio System (QRP, PSK31, antenna, solar panel, batteries)

This makes sense from a development standpoint, given that the boat is an hour and a half away. Weeks slip by as I shuttle back and forth, piddling at measurements and brainstorming, fixing things, and getting immersed in whatever I didn't go there to work on. Like, how did I end up in this huge water project? Oh yeah, I remember... I opened the space above the starboard fuel tank to install the Wema level sensor, thought I'd check to see if the watermaker would fit there, didn't like it, considered alternatives, and ended up thinking it would be great on the aft head wall along with a filtration system. So now I'm deep into fittings, rotameters, pressure regulation, TDS monitoring, and a coherent user interface involving over a dozen valves.

And no, I haven't installed the Wema sensor in the starboard tank yet.

This business of being finite is no less annoying than it was during my more youthful technomadic projects, but of course it is harder now that the toys are growing bigger as the protoplasm grows creakier. I'm not looking forward to some of the projects that are more essential and less alluring... like dangling over the stern with an angle grinder to take dinghy-wounds down to bare metal before infinitely patient rust succeeds to the point where I have to throw another log on to compensate for additional breezes through the cabin.

Much easier to research gadgets online, refine system drawings, and spin 'round in my chair now and then to play Worrisome Blues on the piano...

<ahem> Actually, that is not so far out of context as it may seem... there's real pleasure in this new musical pursuit, now 2 years along. I've played flute all my life, but never with any formality (and certainly never with sheet music, except as an abstract graphic crutch for something I could already play by ear... "oh, it goes up here"). I think one of the pleasures in this nascent ivory tickling is the engagement of wetware bits that are not otherwise being used much; it's a real stretch for these slothful old neurons to get my fingers moving in synch with the chicken-scratchings on the page, but the result is startlingly visceral and I refine it obsessively.

Kind of like sailing. Music is non-intellectual yet immediate, and it wraps around such an elegant conceptual infrastructure that every new discovery is an "aha" moment that reveals the next puzzle in the midst of the rush from clearing up the previous one.

Mathematics is music for the mind. Music is mathematics for the soul.
- Anonymous

Since my "life's work" seems to be characterized by blending all my passions into some kind of nomadic quest, it is only natural that this is going to have to be shoehorned in. The communications console is the logical place, as it already incorporates both computer-controlled crossbar switching (like my old Auxbar design) and a sexy audio mixer. I don't really know where the piano will go; I'll probably end up buying a cheapie and hacking it to fold in half for stowage. That's very much back-burner at the moment, but inevitable.

Audio, Video, Power, Data, Sensors...

The photo below is Grand Central Station from the Microship project, consisting of audio, video, and serial crossbar networks running in networked FORTH 68HC11 boards from New Micros:


I've been tempted to re-use this (among other things, it works, which is a huge plus), but in the interest of scalability I'm using USB-controlled latching relay boards for much of the signal routing. They have near-zero insertion loss, and can be controlled by a small always-on micro, with the boundaries separating audio, video, PTT, and even antique RS-232 endlessly flexible (unlike the strict "data types" imposed by the crossbar design above). It's interesting, though, to see that this problem remains central even 15 years later; part of the whole Shacktopus vision is a unifying layer that erases boundaries between gadgets, and I have yet to find a more effective approach than simply folding everything into a consistent switching matrix with a suitable UI on top.

This brings me back to the console, which has been a sort of mental catch-all zone for yet-to-be installed geekery. Now that I'm laying out panels with actual-size radio templates and the like, I'm finding myself doing a use-case analysis to figure out what is really needed (and where). This is the payoff from the shakedown cruise: such noodlings are no longer abstract.

There are really only a few major "clusters" when it comes to interacting with the techie bits...

1. Navigation: Emphasis here is a decent chartplotter, and (if underway instead of voyage planning) close integration with autopilot, manual steering controls, radar, and general instruments... with ready access to power management and marine VHF radio.
2. Playing radio: Focus on communications, whether ham radio, marine SSB nets, email, shortwave listening, or just tinkering.
3. Audio/Video: Less a mode than a diverse toolset, this includes stereo gear, the piano, mixer, camera suite, signal routing hardware to steer sources to local monitors or into the server for net access, recording tools, and so on.
4. Power: Another "infrastructure" item, including AC and DC controls, battery management, solar panels, generator, shore power, and all the little chargers for hand-held gear.
5. Hacking: The lab, with basic instruments, prototyping, debugging tools, and (importantly) reasonably central access to all signals, sensors, and power-control lines on the ship..
   
6. Shacktopus: Finally, the layer that binds all the rest together... the tools that render everything coherent from any local operating position, including (with relaxed expectations and robust authentication) a remote browser anywhere on the Internet and voice I/O via radio. This includes both "big iron" that is browser-capable, and lightweight always-on micros that maintain a consistent presence at both the back end (data collection) and front end (user interface).
   

The fun puzzle is mapping these very overlapping and intertwined conceptual spaces into actual hardware involving scarce console real estate and bundles of cable. Until recently, I have been assuming that the existing "inside helm" would remain more or less inviolate territory, and the "geeky bits" would all be compressed into what was originally the nav station. Devices that bridge these spaces, like the main Mac LCD, would be on a swing-arm mount to allow use wherever I happen to be sitting.

I've run this photo before, but it's worth including here for visual context:



(That image is a year out of date, lacking the wood stove and the new instrument cluster at the helm... but it is the only wide-angle shot of the pilothouse I have. It was taken by the broker, Cindy Mettler, whose job it was to make the boat look spacious for the Yachtworld listing.)

Now that I've spent 2.5 months aboard, I have a more practical view of how this needs to work. The comm console (past the galley on the left) should incorporate radios, audio stuff, and tinkering tools; that's the most open work desk, and is the obvious spot for front-panel-intensive equipment that is not directly involved in boat operations.

The inside helm, at the right surrounding the big chair, actually has a lot of open space. Everything below the DC breaker panel is obsolete and going away, and the upper right quadrant of the helm itself (above the Yanmar diesel control panel that is peeking around the chair) is a Robertson autopilot that has already been replaced. Looks like the perfect spot for a high-brightness LCD owned by a Mac Mini, running MacENC as well as a browser for access to the ship server. The outside helm, where I actually spend most of my time while piloting, will have an appliance chartplotter for maximum turnkey reliability, but the Mac solution is a much more flexible use of console real-estate below.

If I need system goodies anywhere else, then I can use a laptop. There's a hotspot in the boat anyway, so it doesn't really matter where I'm sitting.

This approach is very liberating, and is a clean break between ship fundamentals and the overlay of gizmology. It also allows better spillover into underutilized console space above the table to starboard, and cabling over there is much easier (especially where power is involved). This is going to be fun.

The Kicker

One quick bit of news before I wrap this up... I finally broke down and converted a month's worth of eBayage into auxiliary propulsion for Nomadling (the dinghy), in the form of a Yamaha 2.5 horsepower 4-cycle outboard. I know. It's hard to be an electric-vehicle purist when I already drive an 18-ton sailboat with two big diesels on board, but I need to reliably make a 10-mile commute each way between lab and moorage to avoid the 54-mile alternative via truck. A quart of gas should do it while being more fun in the process (assuming I'm not trying to haul the table saw), and it's really a sleek little contraption... but I'll reserve judgement until I actually try it in open water sometime in the next few days.

The smaller the boat, the bigger the adventure!

Yarrh,
Steve

Waterworks, Shacktopus, and Simplicity

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.



Shacktopus

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.

Simplicity

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.

Work Trip #2 - Tankage

In what is probably going to become something of a routine, I'm now on my second "winter work session" aboard Nomadness, blogging as I go. Since the last installment, I've done a fair bit on the home front, and also posted an introductory walkthrough of the boat... the first of what should be a large collection of articles by the time this is all over.

But this trip is largely about tankage... I came equipped with three beautiful Wema level sensors, another Maretron TLA-100 for the diesel tanks, the Katadyn 40E watermaker, and a SensaTank II for the new holding tank. It was the latter that I tackled first, as it would be a quickie.

Holding Tank Blues

Like anything on a boat, of course, this little project took about 5 times longer than it should have: find a nearby source of power, splice and run a cable, mount the panel on an unused bezel originally intended for a hot air duct in the forward cabin, locate and mount the three "Mirus" sensor cells on the tank wall after cleaning with Isopropyl Alcohol, wire it all, add labels, and test. So far, so good:


Time will tell how well it works, and if the cells stay attached; polyethylene is not the most chemically active substance. That brings me to the reason for the "blues" in the title above.

Back in August, you may recall, we parked in Port Ludlow for a few days to have some major plumbing surgery done by First Mate Marine. Bob took care of a number of tasks that I would have found difficult or impossible... including the extraction of old sewage hoses (ewww), installation of a new pumpout in the steel deck, and preparation of the Ronco 35-gallon tank for installation on a platform that I built under the forward berth. There were some glitches, but it was a big job with a hefty hourly rate and I was happy to have someone else handling it.

A few days later, the smell began. Bob had used the best quality hose and proper double-clamped fittings, there were no shortcuts, and the tank is 3/8" thick rotomolded polyethylene and thus impermeable. It wasn't making sense, but the cabin would stink after sailing (or sometimes just while anchored in bad weather). More times than I can remember, I sniffed around in there, probing for a clue... even theorizing about air-pressure variations and using my Kestrel weather station to log the barometer a period during which the smell increased. No correlation.

I thought I had the problem solved when I spotted a dip tube fitting that had not been tightened... I managed to get two full turns out of it, as shown in this before-and-after photo:


Smugly, I buttoned 'er up, launched a good-natured jibe at Bob, and moved on to other projects. Only... the problem didn't go away, and it wasn't just residual stale air.

So, while doing the tank-sensor project, I continued the quest. And now I really do think I found it, though the fix may not be as easy. The major fittings were installed with a process called spin welding, in which a special hand-held router fixture spins them in place so fast and with such force that they melt together into a solid unit. That's the theory, anyway, but for some reason the dockside process didn't go quite as planned. Take a look:


I sent this to Bob and he suggested slapping some silicone on it, but I am not so sure... that doesn't actually stick to polyethylene (no goop that I know of really does), though since it only has to fill a void with quite a bit of surrounding material, it might form an acceptable plug anyway. I'm hesitant to try, though, since one thing I learned from my fiberglass years is that once silicone has been on a surface, nothing else will stick. Ever.

I welcome suggestions.

The big take-away from this is not the temporary problem that will certainly be fixable, or even my current annoyance with the contractor. It is the need to be more careful about blithely abandoning my Do-It-Yourself principles when a job looks hard or unfamiliar. $80/hour is more than I have paid for attorneys, and I am now spending my own time troubleshooting and fixing things... reminiscent of the steering pump installation by Anacortes Marine Electronics that included overfilling the fluid reservoir so dramatically that for weeks it streamed down cabin walls and ruined brand new bedding. I paid for that because I didn't know how to deal with the hydraulic fittings, just as I paid for this because it was messy and intimidating (and also because there were a few things, like, ironically, the spin welds, that I don't have the tools to do).

I am more annoyed at myself than anything, partly because I am noticing as I get older that a lot of jobs take longer and are more difficult than they were a few decades ago. Maybe this is normal for aging geeks, but I prefer to think I'm just out of shape... and experiences like this reinforce my lifelong belief that the old saying is true: if ya want it done right, do it yourself!

Besides, I am not part of the mythical deep-pockets "yachtie" demographic, yet the marine marketplace is populated by businesses that expect people to roll over and pay huge labor rates without batting an eye. It is way too easy to underestimate how long something will take, and here there be dragons.

An old lesson learned afresh.

Fuel Sensors, Take One

Moving on to diesel, I started with the tank under the aft berth... that's the easiest one, since it has an existing 5-hole pattern in an accessible spot (the other two will require surgery on the aluminum inspection plates). Of course, nothing on a boat is ever trivial... I found out why the previous sensor had been so liberally bedded in gaskety goop. Whoever did the original bolt circle didn't finish it.

Tapping a hole in an existing fuel tank is nerve-wracking, not just because of chip control but because I kept playing a mental slide show of all the times I've broken taps in stainless. But I proceeded gingerly about an eighth of a turn at a time, and got away with it:


Once the new sensor was snugged down onto its cork gasket, I connected it to the Maretron TLA100... the "tank level adaptor" that converts the 240-30Ω output proportional to fuel level into a PGN (Parameter Group Number) message on the NMEA 2000 backbone, thence to be displayed by whatever system has the capability.

The core device in that department is the Maretron DSM250 mounted at the lower helm. This is a beautiful gadget that can graphically present all sorts of on-board data, and indeed the somewhat random number that had been reported by the original swing-arm float sensor stabilized immediately at 90% (a believable value, as I had filled up just before the pre-election price drop).

At first, however, there was a disturbing phenomenon, reminiscent of some glitches associated with the B&G Network insistence sending 18-degree variation data and causing the compass display to glitch every few seconds. The fuel gauge started doing exactly the same thing!

I wrote to Maretron and quickly got an answer... and it is included here in the hopes that it might save others from similar confusion. When I added the third TLA100 tank-level adaptor, I didn't configure it with a unique tank number. Oops. The phantom "fuel tank 0" interacted with the real one, causing the phenomenon captured above. They are now properly configured as 0 (90-gallon aft), 1 (75-gallon port), and 2 (75-gallon starboard).

The fun is always in the interfacing, isn't it? It's a long way, both philosophically and technically, from a big tank of sloshing diesel fuel to a tidy little graphic that can pop up wherever needed.

Next daylight work session, I'll take on the port and starboard tanks, and I'm now considering the mounting environment for the watermaker and related equipment. I need good filter serviceability, access to valves, and a gravity-feed day tank... all while moving potentially corrosive water-processing equipment safely away from the AC electrical panel where the old one was located. Water corrodes; salt water corrodes absolutely. Candidate locations are the space under the galley sink and the wall of the aft head compartment (space freed by elimination of the old demand water heater).

More soon...
-Steve