IN THIS ISSUE:

Winter is returning to the Pacific Northwest, and we struggle through the acute phase of Seasonal Affective Disorder with a rigorous regimen of Backlight Therapy -- an innovative approach to counteracting the torpor of waning daylight hours based on unblinking exposure to the healing wavelengths of laptop computer screens. The theory is that staring fixedly into the only thing aglow in mid-afternoon at this latitude will compensate for the lack of sunlight, resetting out-of-whack circadian rhythms.

If nothing else, it's a good excuse for prowling the backwaters of ClearStation while muttering acerbic observations about the Clarity of Retrospect.

But with six months to launch, we have entered a period of convergence that challenges my management skills more than ever. To make this work, we must simultaneously perform a range of tasks spanning so many disciplines that it maketh my brain to throb. This week, for example, I'm removing all 132 custom aluminum parts from the boat (including complete disassembly of the landing gear), bead-blasting and documenting them all, then delivering the whole batch to Hytek Finishes in Kent for anodizing... with the ambitious intent of completing deck fixturing and painting while the system is in pieces <chortle>. Meanwhile, recumbent bike nomad and houseguest Ned Konz is deep into the object-oriented design of our linux server code, involving much discussion and nonstop analysis of options I couldn't even imagine a month ago. Lisa is busily glassing her boat, Bob is vacuum-bagging solar substrates in Canada, Tim is testing his 8-channel peak-power tracking system, Bdale is tweaking the Debian linux installation on the Octagon board, and I'm flapping around among my usual time sinks of publishing, learning curves, proposals, documentation, home ownership overhead, and pushing the ever-mysterious buttons necessary to keep this project afloat.

I know: moan, moan, moan. I never used to respect managers, but at least now I understand why good ones are so rare!

MICROSHIP SERVER DEVELOPMENT

This has been a major TBDWL (To Be Dealt With Later) for a couple of years now, ever since we decided to abandon our NewtonScript front end in favor of a browser-based solution. While fiberglass was occupying center stage, it was hard to fixate upon the rapidly moving target of new languages, faster/smaller/cheaper platforms, and yet-unspecified data collection models.

Well, now it's time.

To start the process, we took a dual-Pentium box donated by Matt Hixson, spent quite a few days shuffling drives and boards, bought a load of stuff from an online PC parts vendor that makes up for deceptively low prices with rip-off shipping charges, and at last had a sufficiently robust environment for an install of Debian GNU/linux (the distribution at the heart of Corel's new linux offering). Ned has been fantastic throughout all this -- I never expected a wandering bicycle tourist to have such a wealth of system and software knowledge that he could sing for his supper by running the Microship server development process! Plugging away throughout November, he got PPP, routing, IP masquerading, and demand dialing going... we now connect to the net from our Macs over the local ethernet and out through the linux box (though ultimately limited to the pathetically slow 28K maximum modem speed dictated by our ancient island phone system). The machine also has a browser, Apache, AppleTalk server, X, DDD graphical debugger, drawing and PDF tools, object editors, Sun's new StarOffice Suite, and all sorts of development goodies that are launching me, admittedly with considerable reluctance, into the modern age of software design. Old habits die hard, you know... for a FORTHie who grew up on assembler and wrote lots of spaghetti in his heyday, it's a real leap to wrap my brain around object-oriented Perl and the tools to hack it.

Throughout this process, we've been refining the intent of this whole system... and now view it as a set of processes clustered around a central database and communicating through sockets. Each physical resource is "owned" by a single process, such as the Hub server that controls the connection with the long-established New Micros FORTH board that (together with a boatload of interface hardware) manages the crossbar networks and handles all the low-level I/O on the ship. Any process that wants to talk to hardware, whether to schedule a crossbar connection or snag a snippet of environmental data, thus becomes a client of the Hub server, which in turn handles the gritty details of interacting with the FORTH interpreter.

One of the ongoing objectives here is the collection of many flavors of data pouring in through serial, analog, and digital channels. Readings are time-stamped and dropped into a database, multichannel snapshots are transmitted to the public web server on an hourly basis, equipment-performance datasets are archived for sponsors, and -- depending on the current situation -- any arbitrary set of inputs can be displayed live on the console browser as stripcharts or simulated instruments. A key part of all this is what Ned calls the Realtime Data Broadcaster. In his words:

"The Broadcaster provides a publish/subscribe service for any client interested in receiving realtime data. Clients interested in updates (like graphical control panel applets) are sent new data via Internet domain socket connections. Clients may specify which data they are interested in receiving, as well as at what rates they need to see it. They may also specify a delta window on analog values, so that they are only notified when an analog value changes more than a certain percentage of full scale."

Like the Hub, the database that lies at the heart of all this is insulated from the various clients by a Server -- along with a Storer that's a client of the Broadcaster. This will let us respond to queries with historical sampled data, which may be subject to interpolation or other processing depending on the nature of the channels and how they are being presented.

The fun part about all this, of course, is the variety of applications that now become possible. We started designing the virtual console that will run on the canoe's browser -- it's a configurable screenload of applets including a scrolling chart segment with a current location icon, basic nautical navigation tools, relevant live sensor data, any set of eight moving strip charts vertically arranged on the same timebase, power system performance instrumentation, and links to everything from extensive online documentation to close-up windows focused on single subsystems.

On top of that, Bdale Garbee is currently in the process of testing VMWARE in the Octagon PC-500 board (now running linux) to see if we can realistically drop in a virtual Windows environment for the heavier nav applications. If so, we can put charting software, Sea Station 2000 weather satellite images, Interphase sonar displays, and other Windows-native nautical tools on the same screen, eliminating the dedicated Nav PC that was originally planned! After all, I want to get on with it, not continue repackaging circuit boards into the 21st century...

You know, this is really amazing. Yesteryear's PC fortified with linux is a serious system; boxes that would be destined for the garage sale with their original software can turn into amazing machines with a single download. There's a lot of momentum behind this open-source movement, paradoxically sending stock prices soaring while mounting a diffuse attack on Windows hegemony that must be making people nervous in Redmond. Even with a modest complement of RAM and relatively small disks by today's standards, we think nothing of having dozens of tasks, some of them decidedly non-trivial, going on at once. And when we call on our various wizards for support, they just log into the box from afar and poke around.

Of course, all this will work via the Globalstar satellite link on the Microship as well... the constellation is now up there and testing is underway with Qualcomm tri-mode handheld phones! Stay tuned for exciting news on the mobile Internet access front...

Newton approach
Octagon board
Star Office
Corel Linux
Globalstar
Ned Konz
Debian

APPLICATIONS GALORE...

The closer we get to having an autonomous mobile environmental data collection system, the more we find ourselves thinking about what, exactly, we're going to DO with all this capability. In fact, the more we ponder that, the more we want to port the technology itself so it's widely useful. After all, there's no shortage of environmental challenges that could benefit from a universal, cheap, easily deployed box that can inhale any flavor of sensor data and pipe it to a web server with good visualization tools.

For example, we have an issue here in our own back yard that may well give us some live test data. Camano Island is one of only 68 "Sole Source Aquifers" in the US, meaning that the only water available for drinking is that which fell on the island... no cheating by sucking water over from the mainland. This sort of information is ignored by people whose only interest is clearcutting forest and escaping off-island with their profits... yet it's well understood that the fewer the trees, the more the runoff, and ultimately the greater the salinity of the well water due to seawater incursion. Unfortunately, this is a relatively subtle phenomenon, and as such there's no public outcry when some profiteer rapes the land -- nor are there any laws with teeth to prevent it. If we can deploy salinity monitoring probes, however, and track a few years of data correlated with the forest canopy, rainfall levels, and population... well, it might make a difference.

It's this sort of thing that induced me to extend the Microship data collection system beyond the critical internal monitoring channels such as console pressure and temperature. I have few illusions of doing much in the way of "real science" on the oceanographic scale -- as a technomad I am, by nature, a dilettante when it comes to location-specific projects. But if we collect and transmit a long slice of multichannel data, it can be thought of as a single swath through a vast information space that represents the health of North American waterways. If we go further and publish the details of the system, encourage deployment of multiple boxes, piggyback them on yachts and barges, and otherwise replicate the same basic concept on a large scale, then we end up instead with a continuous flow of location- and time-stamped data from all over the place. Presumably, some inventive folks with GIS software and skills in data reduction could then scale our simple "river profiles" up to a dynamic model of water quality and other environmental indicia, all without massive capital investment beyond individual ownership of little widgets that squirt out a dollop of wireless email now and then.

This would have sounded grandiose a while back, but the more I play with this stuff, the more I realize that all it takes these days is low-power embedded PC hardware running linux with a few sensor channels and suitable datacomm. That's all pretty much off the shelf now, and just needs to knitted together with some clever code.

I share this rhapsody with you as an intro to an interesting bit of news: we're now participating in a National Science Foundation project to do just that, with initial test sites in Wisconsin and Puerto Rico and detailed publication of the complete design. To learn more, including some comments on how the Microship project fits in (see Progress Reports), chase this link...

Biological Projects by Wireless

Before I leave this subject, I should mention a few other applications for our data collection tools. Internal measurements, such as indicators of the sanctity of the pressurized console, are obviously of strong historical interest to me (though probably not anyone else). We're also monitoring meteorological and navigation data, with a Handar ultrasonic wind sensor, Garmin GPS, Ritchie electronic compass, depth sounder, and temp/humidity/barometric sensors. And we also care deeply about the power management system and solar performance -- Tim's magic peak power trackers will be among our data sources, allowing both live and historical strip charts of eight solar panel channels sourcing 60 watts each:

Tim's Peak Power Tracker

And finally, a fellow in Iowa named Paul Leibenow had an interesting data collection idea...

Oh, I almost forgot about Delta P. Your last issue didn't mention a readout for Barometric Pressure in your list of gadgets, so I thought I'd add another suggestion. One of the things they don't tell you about the Puget Sound weather, is what my buddy and I used to call Delta P, or change in pressure. I'm not sure if it's mostly a maritime phenomenon, but I was occasionally extremely affected by the weather when I lived in Seattle. There were days when I would feel like my head was turning inside out. My friend and I would become nauseous/giddy on certain days, and we really couldn't figure it out at first.

I'm convinced you would be doing a public service if you could identify what is going on with the weather out there. My personal theory is that when barometric pressure changes rapidly, it affects the inner ear to such a degree as to cause the feeling of falling in space or rapidly climbing. There were days when NO AMOUNT of espresso would bring even a semblance of normality/energy to the day. If you had a very sensitive barometer that could give you an accurate reading of the RATE of change of pressure, I think you might be able to get some clues. If you could make a numeric readout for the rate of change, similar to a variometer on a glider, then the episodes might be able to be read in real time. If there was a possibility of forecasting it - all the better. I could envision a day when the local TV stations give a DP warning for the following day. (It would probably save people from driving erratically while under the influence and thus save lives... I jest not).

Intriguing concept. We'll have barometric pressure sensors for basic weather monitoring anyway, so it's a small leap to add a bit of processing to explore Paul's Delta-P concept. As a confirmed SAD sufferer, I'm personally curious about this -- there are days when I'm completely useless.

"CLUELESS AND LARK" EXPEDITION UPDATE

Speaking of painful wordplay, this section is primarily a gratuitous vehicle for its title -- the invention of Greg Jacobs upon observing that we'll be following the Lewis and Clark route, but in reverse.

The plan is gradually evolving, by the way. At the moment, it appears that we'll be doing the Perl Whirl cruise to Alaska with one boat, but not launching from the mothership until we've returned to Vancouver, BC (where cranes are more common than, say, Ketchikan). Besides, the Inside Passage would be a bit ambitious as a first shakedown cruise....

We'll then spend June chasing around local waters, with a stop in Cowichan Bay around the 10th of the month for the pedal boat festival. After the big July 4 on-water fireworks party in Lake Union, we'll TRUCK the boats down to the Columbia River, just inside the bar. A recent recon mission convinced us that trying to use the landing gear to make it overland in multiple hops is not realistic, though we ARE planning to make an amphibian Belfair-Allyn run to turn Hood Canal into a loop instead of a dead end.

Damn, this is getting close. We're really going to have to settle on boat names soon... whaddya think, Delta and Wye, or Io and Europa? The latter would add another twist to our BEHEMOTH to Microship T-Shirt slogan:

01 if by Land
10 if by Sea

NEWS ITEMS VARIOUS

Finally, I have various bits of news to pass along...

First, deep thanks go to our newest sponsor, Hytek Finishes, for anodizing the 130-odd aluminum parts on the boat! The 2-hour test sail reported in Issue #131 introduced enough saltwater to induce the beginnings of corrosion on every piece of aluminum, more so where it's in contact with stainless. No surprises there, of course, but it's definitely time to seal 'em up -- and while I did set up a basic anodizing facility that worked fine on the test parts, quality control is an issue. These guys are the pros, busy continuously with parts for Boeing...

Hytek Finishes

Getting the parts ready to send to Hytek required a new toy, one which required yet another new toy. I love it. We made a pilgrimage to Grizzly Tools in Bellingham a few weeks ago and picked up a bead blaster and a 5 HP oil-free compressor to replace the wimpy one from Costco we've been using as a dust-kicker. And speaking of dust, we also snagged a monster air cleaner that's now hanging from the ceiling of the fiberglass shop, filtering out particulates down to 3 microns. Finally, we added R-19 insulation to the whole shop, inspired by a dramatic drop in temperature and another summer of bad planning in the firewood department.

Grizzly

You might have noticed a change in my email address -- I've been meaning to start using wordy@microship.com for quite a while but just haven't gotten around to it. Two mega-thanks are in order here: Qualcomm has been hosting my POP mail server for years, and continues to be a vital network link for us as well as a key part of the Globalstar project as the maker of the CDMA phones. And Zocalo, where the microship.com domain is located, has been hosting our web server for a couple of years now. Many thanks to both companies for keeping us steadily in touch with the world!

Qualcomm
Zocalo

The public speaking business has been unaccountably slow lately (has everyone seen BEHEMOTH by now, or what? ;-), but I've started doing local informal presentations about the Microship project. One was a couple weeks ago for an energetic bunch of sailors comprising the Northwest Multihull Association; the next is February 6 in Seattle for the Puget Sound Repeater Group...

NWMA
PSRG

And last, here's a random useful link: John Shuttleworth's Multihull Design Considerations for Seaworthiness... I stumbled across it a while back and found it excellent:

Shuttleworth

That's it for this issue! Off to bead-blast some rudder control parts....

Cheers,
Steve