The Microship Status Reports

Hiya...
Development is occurring on many fronts! With our first general meeting looming Saturday, I've been trying to nail down some of the issues associated with student projects, and am pleased to report that one has been launched!

Audio Crosspoint System
Isaac Chu is now in charge of audio crosspoint development -- he's been given the offical stamp of approval by faculty (CREDIT), and is preparing to start on this system as soon as I pass along some real specs. He'll be needing an ECE undergrad assistant on this, so if the following sounds interesting to you please contact Isaac directly <ichu@sdcc5.UCSD.EDU> and cc: me.
(NOTE: In general, since we're welcoming a very wide range of levels to this project, I want to try to distribute our most advanced students carefully, teaming less-experienced people with each principal engineer. These teams will congeal and dissolve on a project-by-project basis, and can also be quite flexible to accommodate personalities, interests, and skill levels... so don't worry about long-term commitments. If something sounds intriguing, dive in!)
Anyway, as I mentioned in the Microship Project Catalog, the audio crosspoint system allows any audio device to talk to any other. Fortunately, this is a direct descendant of a similar system we developed for BEHEMOTH, so the analog circuitry and board fabrication of the crosspoint itself are already finished -- we just need the control processor and associated interfaces to the MCS network and the analog board itself. This is the subsystem that will let high-level software create virtual circuits between, for example, the speech synthesizer and VHF marine radio... or the Mac audio port and a speaker driver... or the console microphone and the cellular phone... or MIDI synthesizer and headphones... or anything ELSE you care to imagine.
As with all other embedded control systems, I expect that this will be implemented in a Microchip PIC attached to the multidrop network. Having this one underway soon will give us the motivation necessary to start defining message protocol between the host system (Ampro diskless 386) and residents of the network. Tomorrow I'll call Ampro and see about getting our development system on order -- that part of the project will always be resident here in the lab so that people working on subsystems can wander by and plug into the net anytime for testing.
Isaac asked me to send a general text description of the process, so in the spirit of keeping everyone uppdated on all aspects of the system, I'm sending the general spec to all of you:
Basically, this processor (we'll call it AXBAR, meaning Audio Crossbar), is devoted to the pair of Mitel 8816 chips that route any of 16 inputs to any of 16 outputs. The architecture of this is such that up to 8 such connections can take place simultaneously, and if 16x16 isn't enough, we can just hang another board on the audio bus to double the I/O capacity. >From the standpoint of planning internal data structures and assigning I/O pins, then, it is very important to consider expandability (besides, this has product potential and needs to be flexible).
When the host computer decides, in its infinite wisdom, that a connecton should be made, it will send a text message via the network that may look something like "AXBAR: SPEECH SPKR-LEFT CONNECT" to patch the speech synthesizer to the amplifier driving one of the external speakers (perhaps in anticipation of a status or alert message to the pilot). This FORTH-like postfix notation is what we used on BEHEMOTH, mostly because the board that handled it spoke FORTH and was programmed by FORTH guru Mike Perry. Whether we use similar notation here is open to discussion, but the intent is the same: the AXBAR processor recognizes its address, inhales the command string, and parses it.
The first step is for it to consult its internal map of the matrix status and find a free audio channel. It then does a lookup to correlate human-readable text strings with their corresponding device addresses, constructs the two commands to the 8816 chips required to turn on the FETs at the appropriate points in the crosspoint matrix, and handles the parallel write operation to make it so. It then sends an acknowledgement to the host informing it of task completion -- or an error message if there were no free channels, a device address was not found, or whatever.
Once that is done, it is just as if someone wandered by with a patch cable and physically plugged the speech board into one side of the stereo amp. Things remain that way forever, or until the host issues either a disconnect command or a reset to clear all connections. It could also request a snapshot of the matrix status to update its own records or display a map on the console, check the number of free bus lines, or issue any other status/maintenance request.

* * *
In general, that's the kind of verbal overview spec we'll use to start the process of designing each of the control systems. From a system management perspective, the verbal statement of a subsystem includes the controller, the attached hardware, the software, the package, and anything that's connected to it. Block diagrams, schematics, flow diagrams, and other detailed specs flow out of this initial text description.
I want to start this development project with some of the better-defined and more easily tested subsystems. I've found from previous experience that it is incredibly motivating to be able to turn things on and make them play early in a project -- the night we first got BEHEMOTH's power distribution done and had the lights working was a night of celebration. Considering that the MCS (Microship Control System) is the core of this entire machine, we need to get that running as soon as possible and have it actually DO something besides sit there displaying a DOS prompt. The audio crosspoint may be our first working component, since the difficult analog design is already done (thanks in part to Sony's Steve Sergeant, who did all the op amp circuitry and performance anlaysis for BEHEMOTH).
At the par^H^H^Hmeeting Saturday, I'll show you some of the hardware involved, and we can talk through some of the other subsystems. And I hope that someone out there will team up with Isaac Chu to begin work on this project...

Aqua-mouse Update
OK, maybe that's not it's official name, but I'm tired of writing "waterproof pointing device" all the time. I've mentioned this before -- Interlink donated the DuraPoint (the extra-sensitive one arrived yesterday), and Frank Araullo is actively researching the options of extracting analog data and creating a custom ADB interface, or nabbing the DOS-oriented serial data stream and automagically converting it. We just got a hint that an ADB wizard in Silicon Valley may have already done this, so I've fired off a piece of email to find out.
Frank is also studying the XYZ force-sensing resistor array to see what it would take to generate a "displacement pointer," but at least we have something that will work immediately -- and may even turn out to be the correct solution. Naturally, I'll keep you posted.

Notes On Brainstorm With Dave Wright
My friend Dave Wright is in town this week, preparing to hop aboard a 57-foot ketch and sail to the South Pacific as crew. We hunkered down on the lawn yesterday and chatted about a few things...
First, road-mode. Instead of four flip-down landing gear that retract into stowage cowlings, we will have two detachable struts that stow below deck. When needed, these will plug into the ends of a torsion-bar suspension system mounted athwarships, integrated with the aft bulkhead. The hull stresses should be handled by a deep longitudinal web in the bilge, carried all the way forward to the fixture that receives the hitch assembly. The wheels should be motorcycle wheels, and careful design will be required to predict the stresses encountered on the road and make sure the point loads don't rip the ship apart. I'm still seeking a sharp mechanical engineer who wants to look into this, working with our marine architects and the FEA group to integrate the custom-machined suspension assembly into the hull. This will be a FIRST in boat design (as far as I can determine), is eminently publishable, and possibly even marketable. A way to build a trailerable boat that doesn't need a trailer and chase vehicle... freedom to wander!
The radar antenna and many of the whips, the aft video camera, the radar reflector, and various other bits of wind-catching weight aloft will be mounted on an arch structure at the stern. Antenna interactions will have to be planned for, of course, so some will be up near the bow. RF ground will be extensive copper mesh, glassed into the hull below waterline and connected via copper strap carried up to the gunwhale (to avoid corrosion). This then becomes the center of a star grounding system, with a tab connecting to each piece of RF communications gear.
We discussed making the rackmount hardware in the engineering segment as modular as possible, and postulated longitudinal rails with threaded inserts every couple of inches to which vertical members can be attached. This would allow packaging variations within those two 18 cubic foot bays, opening up the space and permitting more flexible gear stowage. Cabling can be constrained to a cable trough under each gunwhale, with distribution channels to each module.
Finally, we talked of various deck fixtures: vents, Dorn stuffing tubes for cable feed-throughs, a clear acrylic dome hatch, and so on. This thing is slowly taking shape in my head....

Literature Received
Practical Sailor, Nov 1 issue, dealing with electrical distribution panels, problems with teak decks, and air conditioning.
Two thick office supply catalogs from the UCSD Storehouse.