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, Katadyn 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.

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