Ship of Dreams: New Adventures of a Technomad – CQ VHF
There was a point in the 10-year Microship project that I think of as the peak of system design, and only two articles really capture it… the one below, and another in the venerable Dr. Dobbs Journal. I wrote both during a 2-month layover in a rented house in Bellingham where we stayed after first arriving in the Northwest from Silicon Valley, but before buying the place on Camano Island which led us into lab construction and then on to Microship structural fabrication. By the time the boat itself was “done,” I was already thinking of updating the systems, and then life changed and another decade passed. Now (in 2014, as I write this introduction), I would take a different approach entirely… yet this whole system works beautifully and is a sort of museum piece in my lab. If nothing else, the article below expresses the obsessive technopassion that went into the project…
This magazine cover photo shows me posing with BEHEMOTH in a park near my old Apple-sponsored lab in Santa Clara, and nicely features the communications bay in the rear of the bike’s trailer.
by Steven K. Roberts, N4RVE
CQ VHF
April, 1998
You may remember seeing and reading about N4RVE’s bike-mobile adventures across America as shown on this month’s cover. Now, for the first time in print, here are the details of Steve’s next venture — on the Microship.
It was 1983, in the middle of 8-land… a place of vast cornfields, dreary winters, muggy summers, and suburban sprawl. Bouncing around my mortgaged acre in a blue haze of lawnmower smoke and halfheartedly consulting for local industry, I slowly rankled… why was I doing things I no longer enjoyed to pay for things I no longer wanted? Was this the American Dream? What happened to the grand technopassions that had, not so long ago, kept me up all night in a delicious coffee-wired frenzy of wirewrapping and hacking?
And so, at the age of 30, I hit the RESET button on my life: a “wetware” Control-Alt-Delete. Relationships, real estate, possessions—all faded into memory six months later as I pedaled out of town on the Winnebiko, a custom recumbent bicycle carrying a 32-K laptop computer and 300-baud acoustic coupler, a 5-watt solar panel, security system, and camping gear. For 10,000 miles, I wandered America and wrote tales of adventure, slowly realizing that I had stumbled upon something timely and significant: nomadic connectivity.
But more personally important, the passion had been rekindled, and I wanted more, much more! The Winnebiko II was the next logical step; one that offered a level of integration that allowed me to write and communicate while riding. With a binary handlebar keyboard, console computer system with TNC and 2-meter multimode rig, cellular phone with modem, 20 watts from solar panels, and an HF QRP rig in the trailer, I roamed the land with even more freedom than before, typing in ASCII, unconstrained by the availability of phone jacks and AC outlets. Another 6,000 miles floated under my wheels, while inside burbled a Geek’s Fantasy of epic proportions: BEHEMOTH (an acronym for Big Electronic Human-Energized Machine, Only Too Heavy), shown on this issue’s cover.
The megacycle (shouldn’t that be megahertz?—ed.) rolled out of the Bikelab in 1991, all 580 pounds of it (400 for bike and trailer, 180 for gear). This required a 105-speed transmission to handle the hills, pneumatically deployed landing gear to stay upright when moving at a crawl, and an active helmet-cooling system to prevent the bio-engine (me) from overheating…technology to compensate for the weight of the technology.
Ah, but the on-board systems! There’s a 72-watt solar array, speech synthesizer, ultrasonic head mouse for cursor control, helmet-mounted display, console Macintosh computer, three PCs, a SPARCstation (it’s a unixcycle), Icom 725 HF rig with deployable all-band dipole of Outbackers, Yaesu FT-290/790 VHF/UHF multimode rigs with ARR preamps, AEA ATV box, high-speed cellular modem, six-level security system, GPS (Global Positioning System), Qualcomm satellite earth station for continuous Internet connection, and embedded resource management processors… yes, this was indeed a bicycle built to delight the Hacker Within (not to mention the ham within). I even clamped a pair of KLM crossed Yagis to the HF mast one evening, aimed carefully, and pedaled slowly down a Silicon Valley avenue chatting bicycle mobile via OSCAR 13 with a chap Down Under.
The only problem was that after 17,000 miles of pedaling, I was starting to gaze wistfully over every sparkling watertop, yearning to be on a boat in a magical place without traffic and hills. And that is why, after accompanying me on over 150,000 miles of speaking tours, BEHEMOTH is moving this fall to the Tech Museum of Innovation in San Jose, California (actually, it went to the Computer History Museum).
The Microship Project
But the road, once begun, never stops, and returning to the illusion of stability was never a realistic option. The past five years have thus seen an asymptotic (describing a straight line that approaches, but never meets, a curve —ed.) approach to our ideal substrate for aquatic technomadics: the Microships. My partner, Lisa, KF6NWO, and I are now entering the final systems integration phase on a pair of tech’ed-out pedal/solar/sail trimarans with (take a deep breath) deployable wheels, satellite net connection, environmental data collection sensors, digital video editing capability, computing and communication systems galore, and the essential suite of navigation tools, not to mention a number of packet and voice links among boats, backpacks, and the outside world.
Putting It in Context
A bit of context is in order before we talk about on-board systems. The objective is open-ended adventure (on the order of years) along coastal and inland waterways, not sailing around the world. Without trailers or other land support, we need to be able to haul out easily for camping or portage, hence the light-weight deployable wheels.
These little 19-foot boats fold from 11 feet to four feet wide for storage or transport, support basic on-water bivouac, and carry the essential life support tools of cooking gear, water filtration, personal foulies, medical supplies, and so on. This combination allows open-ended exploration without the substantial overhead (and limitations) of dependency upon marinas, trailers and tow vehicles, paved launch ramps, and other infrastructure. These are human-powered canoe-scale Microships, not yachts.
How They’re Built
The center hull of each Microship (see Photo A) is based on a Kevlar™ “Odyssey” canoe from Wenonah, with deck structure built in our lab of Divinycell foam core, fiberglass, and epoxy. The pilot reclines in a webbed recumbent bicycle seat facing a pressurized control console (I’ll explain why later), with helm and system controls convenient to both hands (including hydraulic steering levers, control lines, chord keyboard, pointing device, thruster and power controls, communications console, and so on). This position is optimized for pedaling, since a custom drive unit can be deployed to allow human propulsion at about 4 knots via a 12-inch two-blade prop spinning at nine times the pedaling rate.
In addition to running on fish and pizza, the boats can, of course, be sailed, and there’s also a steerable Minn-Kota electric motor in each one, delivering 42 pounds of thrust at full power.
Since our meager weight budget only allows a single deep-cycle battery, which is largely devoted to system loads, we carry rather huge photovoltaic arrays — 480 watts per boat of Solarex 30-watt ultralite modules, laminated onto a hinged foam-core substrate that can handle body weight, float, and retract in heavy seas.
In ideal conditions, this 50-square-foot solar array can produce about 32 amps of 12-volt power, enough to push the motor to full thrust. The catch, of course, is that ideal conditions are rare in this environment (rig and console shading, dirt, heat, and other on-board loads thirsty for the same resource), so each boat carries a dedicated power-management processor that takes a snapshot of the whole power system every few seconds, then calculates a “free power” value that’s defined, for casual cruising purposes, as maximum throttle. In an emergency, this can be bypassed to yield about two hours of full thrust before the battery is exhausted.
Underground at Grand Central (sidebar)
As mentioned in the main text, the serial crossbar (Sexbar, at lower right in Photo B) allows four simultaneous bidirectional connections among 32 channels, 28 of which are available as a 4 x 7 array of DB-9 connectors. If the hub controller decides that it wants to send a string from its aux port to the speech synthesizer, for example, it just executes a simple FORTH command (AUX SPEECH SCONNECT) and the result is exactly as if someone had wandered by and plugged in a serial cable, with connections established between pins 2 and 3 of the named connectors. Of course, serial connectors often have their pins swapped from what we expect—how many hours have you spent unsoldering and resoldering pins 2 and 3? I worried about this while designing the Sexbar, since the whole idea was to provide enough flexibility to allow new devices to be easily added later.
The solution was a window comparator, along with a bit of code that scans the four involved pins on every connect request: if the level is between +/- 2.5 volts, then it’s a fair bet the pin is a receiver; outside that range, it’s a transmitter. Since we have full switching flexibility through the Mitel 8816 crosspoint chips, it’s then a simple matter to conjure a “virtual straight cable” or “virtual null modem cable” as necessary. (The full Sexbar design is available as a PDF.)
The Auxbar, or audio crossbar, subsystem (large board in Photo B) provides the same level of flexibility for our audio sources as the Sexbar does for digital data. It doesn’t need to auto-polarity sense, of course, but it does have to maintain line levels through the network to minimize insertion loss and compensate for sources that are hotter or cooler than others. Two stacked PC boards (first developed for BEHEMOTH) each allow up to eight simultaneous connections among any of 16 sources and 16 “sinks.” To allow expandability, those eight buses are brought out to the board edge, allowing us to easily scale up the Auxbar to 32 x 32.
One evening, just for kicks, we made a quick setup macro. With one click, the ICOM 725 was commanded via the Sexbar to the NAVTEX frequency, its audio output routed via Auxbar to the KAM+, the resulting serial data piped via Sexbar to the “Audapter” speech synthesizer, and its audio linked to a little Ramsey FM transmitter. We walked around the lab listening to live Coast Guard weather beacons on a Walkman. The whole process only required five lines of code.
Finally, Vixbar, the video crossbar, is packaged directly on a dedicated New Micros FORTH board (right center in Photo B, marked “V”), with four Mitel 88V32 chips allowing any of 16 video sources to be linked to any of eight downstream inputs. Optimized for video, these carry full bandwidth and even allow frame-synchronized switching to minimize screen glitches.
Water Worries… and Wonders
The consoles I mentioned a moment ago are among the most critical aspects of the whole design. BEHEMOTH was loaded with electronics in a “waterproof” console, but it only had to withstand fresh water sprinkling out of the sky. At sea, we have a whole different problem: a pervasive corrosive environment that will ruthlessly attack anything electronic (“Water corrodes. Salt water corrodes absolutely.”). To deal with this problem, the consoles are not only sealed, but pressurized to a fraction of a PSI (pounds per square inch) above normal air pressure, allowing a processor to periodically shut off the air supply and check for a pressure drop uncorrelated with temperature change that might indicate a leak.
And all of this exists to allow us to wander the world’s waterways, living on the Net, hobnobbing on the airwaves, gathering and posting environmental data, publishing tales, producing videos, and generally frolicking in that strange technomadic domain where bouncing data off a satellite seems a perfectly normal thing to do around the campfire.
Making a Beeline… (sidebar)
The Beeline network is a multidrop cable that connects all of the nodes scattered around the ship (see Figure). The “boss” of the network is the Hub, a pair of 68HC11 FORTH boards (Photos C and D). It selects a node by sending a single-character node identifier with the high bit set. All notes see this high bit, check to see if they’re being called, and then return to whatever they were doing… except the lucky one, which immediately turns on its transmitter to establish a bidirectional link over the Beeline. At this point, the network acts like a straight serial connection between the Hub and the selected node. It’s elegant, simple, fast, and easily expandable.
We picked the 68HC11 boards—even though the HC11 technology is 10 years old—because they’re very easy to interface and the software for using them is so simple. Plus, the FORTH is in ROM, which lets you bypass the traditional edit-compile-download-debug cycle familiar to anyone who codes in C or assembler language. This is the technology of instant gratification, and, for an embedded control environment, I can imagine nothing more pleasant.
Layered atop the internal FORTH is a pair of tools written for us by Bill Muench. The tight little multitasker and the multidrop network tool takes advantage of the four-wire RS-485 standard. The net effect is straightforward generation of small autonomous tasks, along with the ability to hang up to 128 nodes on a long bus, each of which presents its console port to the upstream machine. (The network cable also carries a NETRESET line to allow automatic cold-start and code reload if watchdogs detect failed nodes.)
Looking again at the Figure, you can see some of the implications of this. The Hub’s console port accepts simple ASCII commands from any communications program, so writing a graphic front end is a simple matter of associating transmit strings with various mouse clicks and linking returned data with appropriate graph- ics, such as a bar graph for temperature. We’ve done this, with equal ease, in both HyperCard and NewtonScript. The latching serial switch atop the Hub allows the board to reroute its own console to a channel on the Sexbar, making it possible to log in from a distant wireless system and seize control of the network. On reset, it defaults to the console Macintosh to allow recovery from a crash.
Control Network and Resource Management
Now let’s take a look at the core of the Microship control network. Bear in mind that we have a huge variety of problems to solve, including audio and video signal routing, data collection and reporting, security, power management, thruster control, personal communications, diagnostics, system monitoring, and so on.
While it’s often suggested that we install one monster computer with a Web-browser front end and a high-speed communications network encompassing all peripherals, the power demands of such a machine would be way outside our power budget; and most of the serial devices we use are far too “lightweight” to accommodate proper networking via a TCP/IP protocol stack. Also, we theoretically could handle all audio and video streams digitally, but the power cost of that approach in what amounts to a solar canoe is currently unreasonable.
What we really need here is an adaptive Internet-linked control environment that only sucks current when and where necessary, can painlessly interconnect random signals, transparently works as a single system spanning two boats and two backpacks, is easily hackable in the field, and can be viewed by the users at any level from gritty bits-between-your-toes detail to point ‘n click pretty pictures. The result, shown in the Figure, has been developed over four years through our own efforts at Nomadic Research Labs, aided by dozens of creative industry and student volunteers.
A couple of key concepts must be understood before the applications make sense: crossbars and multidrop networking. The core of the whole Microship system depends on these two fundamental architectures, which we call Grand Central Station (see Photo B) and the Beeline network.
Grand Central Station: Sexbar, Auxbar & Vixbar
The three rounded boxes in the Figure give us an immensely powerful, yet simple, tool. Each is a crossbar switching system optimized for one of three signal types: serial (data), audio, and video.
The serial crossbar (Sexbar) allows four simultaneous bidirectional connections among 32 channels, 28 of which are available as a 4 x 7 array of DB-9 connectors. The Sexbar lets the Hub (the master network controller) route any serial data stream to anywhere it needs to go, and we’re well on the way to having a universally reconfigurable system (for technical details on the system, see “Underground at Grand Central”).
Next door is the audio crossbar (Auxbar), which gives us equivalent flexibility with the surprisingly large number of audio devices on board. Like the Sexbar, this solves a nasty resource management problem: we may want the CD player to go to the speakers, for example, but have one channel automatically overridden by an incoming transmission from the other boat. This completely eliminates the need for multiple heavy speakers, a thicket of dangling microphones, and a nightmare maze of switches and patch cables. Most serious ham shacks could benefit from one of these, but on a tiny boat the need is critical.
The final component in our “Grand Central Station” system, the video crossbar (Vixbar), is at the bottom of the Figure. With six or so cameras scattered around the boats, wireless video links, a Draco Casablanca editing system with 9 Gigabyte hard disk, frame grabber, and remote controlled Sony 8mm VCR, the Vixbar is every bit as useful as its cousins.
Now that we can connect anything to anything under software control, let’s take a look at the network itself.
The Beeline Network
We searched far and wide for the ideal hackable, low-power, I/O-rich suite of embedded controllers, and chose the 68HC11 FORTH boards from New Micros as our network control Hub (see Photos C and D; for technical details on the network, see “Making a Beeline”). Things get interesting when the Hub connects itself via the Sexbar to the Beeline network and begins a task called NODESCAN, which hits all the nodes every 15 seconds to update an internal variable table. It can also asynchronously send commands to any node, making the whole thing feel like one machine simultaneously running a vast collection of different tasks involving widely diverse bits of hardware.
The sealed video turret, for example, can point either a zoomable color or IR-sensitive black-and-white camera at any angle, or scan between any pair of angles at any speed. The thruster task scales the propulsion system to the available solar power budget. The data collection system busily gathers internal and environmental data for transmission to a Web-accessible database server, and the Hub itself monitors and controls the most critical subsystems (like security and console pressure) since it is always on.
On top of all this, we have a high-level network that includes a terminal server, essentially creating a transparent link between a remote graphic machine via wireless Ethernet and that vanilla ASCII console port that runs the whole show. The problem, of course, is that all this high-level graphic stuff is larger and more power hungry than we need for minimal day-to-day remote backpack operation… so we’ve added packet radio.
Packnet—A Simple Wireless Network Extension
Did you notice Node X in the diagram? Think of this as “Xternal,” as it lets us bring the other boat into the same network environment. Node X gets connected to a PacComm TNC via Sexbar, which is in turn linked to a repackaged UHF HT via Auxbar. Push-to-talk is generated by simple arbitration logic, since we also want to be able to transmit voice, synthesized speech status reports, and other audio over the same radio under Hub control.
Some distance away, bobbing on the waves, is the other Microship, with a similar TNC and radio connected to the first one (for network purposes, this is Node Y). Node Y’s console port is thus linked via packet to the auxiliary serial port on Node X, allowing transparent communication to take place as if it were a hardwired node on the Beeline network (although slower, of course). This brings all the local I/O on the second boat under the purview of the primary control system, effectively linking them into a single network. (Note, by the way, that the pilot of the second boat can override the console connection of Node X in order to directly access local resources.)
Don’t Forget the Backpacks!
Not shown in the drawing, but equally straightforward, is the configuration of each backpack. When off the boats, my partner and I need to be able to stay in touch, check status of unattended systems for security purposes, and locate ourselves relative to each other and the boats. Our packs each carry a small 70-centimeter HT, a Mic-E (APRS mic encoder) from TAPR, and a Motorola On-Core GPS receiver, along with a small palmtop computer with a separate high-speed wireless network link.
The Mic-E automatically tails voice transmissions with GPS data and sends the same burst on a scheduled basis if we’re not chatting. It also offers a few status bits, giving us the wonderful opportunity to implement a one-button “where are you?” function that prompts the Hub to perform great-circle calculations on GPS data for both packs and both boats, then speak the range and bearing with the synthesizer over the same radio link.
Another button invokes a general system status report, another is an emergency call, and yet another fires up the “big iron” via Hub power control tools to allow a full-scale remote graphic front end that is identical to the one present on the boats’ consoles. Plus, a DTMF receiver on the Auxbar adds unlimited, though not particularly intuitive, remote control options to our arsenal.
Project Status
As you can see, the effect of these networking tools is to allow the addition of all sorts of applications and interfaces that may not be obvious during initial design phases. This design keeps up-front hardware development at the very general level of interconnect infrastructure, with applications almost entirely implemented in software. With total control over power switching, general parallel I/O, serial interconnects, audio/video routing, and even the overall network architecture, it’s easy to add functionality down the road without spending much time over a hot soldering iron.
At this writing, we’re setting up the new Microship lab and home base on Camano Island, Washington. Most of 1998 will be taken up with packaging and test sails in the rich waters of the Pacific Northwest, and, by Spring of 1999, we hope to be launching for our first major adventures: a long drift down the Missouri River from Montana, to be followed by a circumnavigation of the Eastern U.S. on coastal and inland waterways. Stay tuned!