As I settle into Datawake, wrapping myself in a console of rackmount blinkies, I often reminisce about the obsessive Microship project that occupied me for almost a decade (1993-2002). This amphibian pedal-solar-sail micro-trimaran is still in my life, and the plan is to launch it from the upper deck of my new mothership for local exploration.
But with all the photos online of this geeky little sprite (including the 2013 launch), there is a huge part of her history that has been lost in the murk of archived mailing list posts and a creaky old album of low-resolution images from the mid-90s. With this post I want to fix that… so I just dusted off the mountain of Microship electronics in my lab and took a few photos.
The goal of this system was to provide a rich toolset with a graphic front end and an always-on controller. To avoid having to re-invent dozens of wheels, my general design strategy was to take every object (usually a commercial product, unless none existed to accomplish a task), and reduce it to standard interfaces — audio, video, serial and power — then tie it into a huge crossbar switching network.
The beauty of this is that anything could be connected to anything with a single line of FORTH code, making it trivial to conjure applications that I might not have imagined at design time. It also made it easy to add new devices, like a piece of ham radio gear, without having to tear up existing wiring. Obviously, some of this is getting a bit dated now, with cheap and low-power devices like the Raspberry Pi and general improvements in standardized interconnects (like USB), but we still have the same basic problem when building huge systems… lots of things that were never meant to talk to each other, creating redundancy and complexity.
The Microship user interface, in its final form, was a mix of wireless Newtons and a web browser in the console Macintosh. One of the most fun contraptions was the video turret, which could point a hacked camcorder or low-light B&W camera at any angle, or scan between a pair of angles. Zoom could be controlled, and a servo-operated “lens cap” protected the CCD from being parked pointing at the sun. Here is what it looked like from the operator perspective… and with the video crossbar, feeds from the cameras could then be piped to a recorder, transmitter, display, frame-grabber, or whatever. Implementation details were wrapped in code that could be easily modified down the road without an epic hacking layover.
The machines shown here were built in my three Microship labs, with lots of help from volunteers, students, and industry sponsors:
- UCSD Electrical & Control Engineering Dept, San Diego, CA (1993-1995)
- Microship lab sponsored by Apple Computer in Santa Clara, CA (1996-1997)
- 3000 square-foot lab in the woods on Camano Island, WA (1998-2002)
Without going into much technical detail, here’s a look at the Microship hardware that is gathering dust on the shelf in my lab. All photos can be clicked for huge versions…
Grand Central Station
The crosspoint switching systems for audio and video make up this first assembly, each controlled by a 68HC11 running FORTH. The blue board on the right handles 16 video inputs and 8 outputs, with up to 8 simultaneous connections (via the RCA panel on the left). The 2-board stack in the middle takes care of all the audio routing, with up to 8 connections at once among 32 inputs and 32 outputs.
In the Microship system, the AUXBAR and VIXBAR boards were at the center of the analog cabling nexus:
Those audio circuit boards were designed by Steve Sergeant in my Bikelab at Sun Microsystems for the BEHEMOTH bicycle project back in 1990, and provided a very clean line-level signal path. They scaled well to the much larger Microship system.
In the days before USB, serial data communication was pretty much all we had without spending a ton of power on proper networking… and every old-timer remembers endless fiddling with RS-232 connectors, gender changers, DB9 and DB25 adapters, unsoldering and swapping pins 2 and 3, and generally cursing at the damn things.
When I found myself with dozens of serial devices that had to be involved in both hierarchical and peer-to-peer connections, I decided to solve the problem… and that is what led to the SEXBAR, or serial crossbar. Anything plugged into this will talk to anything else, assuming the same baud rate, and the FORTH code accomplishes that by first connecting pins 2 and 3 of each involved device to a window comparator, seeing who’s transmitting and who’s receiving, then creating a virtual straight cable or virtual null-modem cable as needed:
And here is the painful point-to-point wiring at the bottom of that assembly:
So that stuff takes care of all the signal routing… what actually ran the show?
Microship Control System
I won’t go into detail in this photo essay, but if you want to know what is actually going on in this system, I wrote a fairly detailed piece in the June 1998 issue of Dr. Dobbs Journal. Of course, we didn’t have many pixels in our digital cameras back then, so the photos here are much better.
The controller is a folding assembly with an insulation displacement kluge board on top of a substrate that has a New Micros FORTH 68HCII on one side and lots of I/O on the other… with all the interfaces brought out to wonderful Phoenix contact blocks:
Here’s the bottom, with the FORTH board:
(The battery holder was to keep the static RAM contents backed up.) Machined rails were used to carry the boards and allow easy opening for hackage….
And I mentioned those contact blocks… like the connector arrays of the crossbar networks, this made it very easy to get at port bits, serial ports, random signals, or even the bus:
In fact, this was so convenient that the kluge board didn’t get nearly as much random added hardware as I had anticipated. The little cluster of chips at left drives a matrix LED assembly and allows it to be used as a virtual front panel of sorts, mapping random I/O bits to positions on the display:
(The DB-25 connectors link this to the crossbars and other nearby hardware.)
By the way, you can actually watch some of this work! An excellent video by Stan Bunger aired on KRON New Media News in April, 1998… and there are some great shots of this system as well as a thoughtful overview of the entire project.
At the beginning of this piece, I showed a fuzzy magazine image of the turret control screen from my Newton… here is what it was controlling. The full documentation for this (including mechanical drawings, schematics, and FORTH code), is at the Video Turret page on this site.
The platform carried the innards of a Sony camcorder, and its servo-controlled retractable “lens cap.” There is also a laser, allowing a steerable pointer, because, well, laser….
This was in a sealed and gasketed acrylic cylinder with mil-spec connectors to the shipnet, and was controlled by another FORTH board:
And this interfaced with the mechanical system, which included a gear motor, shaft-position encoder, and geared-down cam to detect crashes and end-states…
The code for this lived in 8K of memory, and that included a cooperative time-slice multitasker by Bill Muench that really simplified operation of this very stateful machine.
One of the design goals of the Microship project was full access to all on-board services and communication links regardless of whether I was aboard, off in a restaurant, camping ashore with boat on a mooring, or (to a limited extent) far away. Lacking the kind of ubiquitous networking we take for granted today, this translated into a manpack that was essentially a miniature of the crossbars and other on-board resources… with ham-radio and wireless data tools to stitch it into the mothership. Naturally, this used another of those convenient New Micros FORTH boards:
Like the kluge board on the main control system, this took advantage of the Robinson-Nugent QuickConnect wiring system (much lower profile than wirewrap, but the same #30 Kynar):
Finally, we had a huge system devoted entirely to power… beginning with 480 watts of folding solar panels filling the spaces between the hulls. At the time there were no commercial peak power trackers, so my friend Tim Nolan designed and built this beautiful machine… with four PIC microprocessors each handling two 60-watt modules and optimizing their power transfer into the batteries by manipulating the pulse width to reflect the product of voltage and current:
The assembly at lower left (two identical boards, stacked) take care of the solar array, then the commercial board to the right of that drives the Minn-Kota electric motor. One of the fun features of this, managed by the system at upper left, is that once all charging and system loads were satisfied, any left-over “free” power could be piped to the thruster. This would track conditions of insolation and local power demands, generally contributing a boost on a sunny day whether sailing or pedaling. There was also an “oh shit” mode that could be invoked when on a collision course with a freighter, dumping all available solar and battery power into the thruster. At such moments, the future status of the battery is not interesting.
That unit also drove an 8-line LCD that displayed real-time detailed information about the power system, with all the battery and load monitoring measured by those shunts in the upper right.
All that electronics is a bit long-in-the-tooth now, and one of the lessons from that whole project is that when building a boat, don’t build the geeky bits until the fiberglass is done! A few years of my life are represented in those photos above, but no regrets… the journey is the adventure. The next phase of the Microship’s life will be relatively low-tech: she will be crane-launched from Datawake for local jaunts, carrying little more geekery than cell phone, chart plotter, marine VHF, and LED navlights.
Cheers from the San Juan Islands!
— Steven K. Roberts