Microship Hub Overview

It is both delightful and scary to have so many knowledgeable people on this mailing list! No technical error in my tales goes unreported… in response to last week’s April Fools issue (#101), I received detailed explanations about GPS encoding from both NASA’s Jet Propulsion Labs and the Department of Geodesy and Geomatics Engineering at the University of New Brunswick. (It seems that my allusion to “creative P-code decrypting” would NOT have had anything to do with bypassing Selective Availability.) And two local mariners pointed out that zebra mussels are *freshwater* mollusks, and thus make no sense in the context of my speculation about Faun’s saltwater hydroponic ecological pest-redistribution project. Noted… and thanks to all four gentlemen who wouldn’t let me get away with factually-flawed humor!

(We also had three people who took the posting very seriously, one of whom left the mailing list rather curtly because our “research directions are no longer of interest.” <sigh>) Anyway, we return to reality with this issue, and we actually have some to report…

by Steven K. Roberts
Nomadic Research Labs
Santa Clara, California — April 11, 1996

(Issue #102 of the Microship Status Reports)

Hub Documentation

Since I’m about to get back into the shipnet system by integrating the serial crossbar network (SeXBAR) with the Hub instead of a dedicated node as originally intended, I started deciphering my previous designs… discovering to my dismay that they were still scattered about in various notebooks (the spiral kind), file folders (the manila kind), and scraps of paper (the lost kind). This seemed like a perfect opportunity to launch myself into the DesignWorks learning curve… the newly-donated schematic capture package from Capilano has been sitting here untouched since shortly after MacWorld.

It was a challenging few days of puzzling over the trade-offs of hierarchical vs flat design paradigms, device editing, sheet format standardization, unfamiliar terminology, and so on… but it finally clicked. The hub core is now a lovely 3-page schematic, greatly clarifying the interface projects that lie ahead. In particular, the next step is to connect the 32-channel serial crosspoint matrix (built by UCSD students Jeff Simon and Dan Sebald with four Mitel 8816s) to the “nexus” board atop the hub, then cable it, along with a lot of other I/O, to an array of Phoenix contact blocks to provide clean interconnects to the ship. This will complete I/O central, which also includes the 32×32 audio and 16×8 video switchers. At that point, the signal-routing infrastructure will be considered complete and we can turn our attention at last to the sensor array and various control systems.

DesignWorks is an excellent schematic capture tool for the Macintosh, and it includes a lot of cool features I don’t need at the moment — full logic simulation complete with live timing diagrams and probes, netlist export to PCB packages, PLD design, and so on. A nice side benefit is that it can export designs as PICT, so we will be able to include the images in our Web site and the printed monograph series.

Hub Overview

All this recent wallowing in the gritty details of the Microship’s control Hub makes this a good time to give you a quickie summary of operation. This is a distillation of the often-conflicting details that have been reported in this series over the past couple of years as the system has developed…

Basically, the Hub is the interface that lies between the network of four Macintoshes (two built in, two in wireless-networked backpacks) and the multidrop network of multitasking FORTH boards from New Micros. The latter are charged with most of the standalone control tasks, such as solar peak power tracking and performance monitoring, thrust and regeneration control, rigging stress analysis, hydroponic garden management, neural net autopilot, A/V channel routing, video turret control, enclosure pressurization, and all that. The hub, being centrally located in both net-topology and physical realms, ends up handling communications with the nodes as well as anything that is general in scope… such as security, fault detection, emergency conditions, and low-level connections from the backpacks.

In practice, this translates into a lot of I/O and a bunch of simple handlers, as well as a global variable table updated by a node scanning task, used for local code and exported on demand to the Mac graphic front end. The hub (also based on a FORTH board like the others), has a 34-pin ribbon bus to five 2×4″ peripheral cards that add 64 input bits, 64 output bits, a flexible serial channel, real-time clock, and 3-channel 16-bit counter to its standard 68HC11 interface repertoire. The real-time clock drives a task that does a security scan based on operating mode (watch, sleeping, normal, unattended, etc), as well as testing for any kind of failure mode that would constitute an alarm condition (dying batteries, too much bilgewater, equipment failure, enclosure temperature or humidity limits exceeded, carbon monoxide or LPG sniffed, and so on). It also periodically scans the network for health status, and signals the Mac to log, reload, and/or restart an ailing node.

The hub is the boss of all the low-level serial routing, which is distinct from high-level networking at the system level. We’re not turning speech synthesizers and GPS receivers into network-aware TCP/IP nodes; instead, all the little stuff like that appears on the 32-channel serial crosspoint switch. Anything can talk to anything, meaning that with very few lines of code we can snag the compass heading and GPS fix (for example), construct a status string, and speak it via any of the audio channels… just by sending three commands to the SeXBAR and one to the AuXBAR.

Perhaps the most twisted part of all this lies in the domain of the “power steering” board. The latter half of the name is due to a pair of latching relays, carefully defaulted on reset or power-up, that allow the hub’s console port, the external serial port, and the multidrop network itself to appear as channels on the serial crossbar. This will permit hacking, basically — I’ll be able to log in remotely and sieze control of the hub or network (or otherwise permute normal operation for diagnostic, development, or techno-amusement purposes). Functionally, it’s just a decode of a couple of HC11 port D bits that drive the relay coils for a few milliseconds, allowing redirection of the otherwise sacred console-hub-network connections to channels on the SeXBAR system. I briefly contemplated avoiding the apparent redundancy of this by making them ALWAYS be SeXBAR channels, but the potential for lockup on software crash is obvious.

All this has been under development for quite a while, and with recent forays into sensors and interesting applications, it is about to become a heavily-used development system.

Differential Thrusters

In the week before the April Fools posting, Faun and I flew to San Diego for three days to attend (and speak at) the SAE Electric Vehicle conference. It was most illuminating… this was a gathering of automotive, battery, motor, flywheel, and power engineers, as well as a number of fascinating and utterly uncategorizable folks including Amory Lovins and Chester Kyle. It was a high-density information infusion, and my own luncheon keynote led to a few good connections.

In particular, we’re now working with JWA Marine (Minn Kota motors) as a new equipment sponsor — a pair of their 70-pound thrust submersible motors are soon to head this way, and our job is to pass along whatever we develop from the attempt to perform power regeneration under sail or anchored in current (likely to involve a retrofit of additional brushes at a different phase angle). Yes, there are more efficient rare-earth magnet motors out there, but they are generally thousands of dollars and not even remotely “marinized.” Minn Kota units have been available for quite a while as trolling motors, come with PWM controllers, and they’re well along the packaging learning curve for the harsh marine environment (a wheel I hope to reinvent as little as possible!).

Our installation is going to be rather unusual. We’ve puzzled for some time over what appeared a no-win trade-off of two thruster options (disregarding the motor technology itself): inboard vs outboard. The former has the advantages of clean installation, shorter wire runs from the battery bank, no surface-piercing ventilation effects, and less dependence on sealed packaging; the disadvantages are a through-hull propshaft fitting, the need for an expensive variable-pitch prop, the potential for grounding damage, and (most annoying) the loss of low-speed maneuverability due to the trimaran’s narrow hull form. The pivoting outboard option, on the other hand, offered an easy solution to this last problem, easy installation, and off-the shelf availability… but it potentially interfered with rudder and windvane, was ugly and heavy, and at $4,000 for the unit of choice would be an attractive theft target hanging out there in the breeze.

The Minn Kota thrusters, however, offer us a new option. At the stern of each ama, we’ll build an aluminum pivoting mount with four positive detents. Lines will allow detent-retraction and 360-degree motor mount rotation from the cockpit, allowing the drives to be deployed or retreived in either position of the folding crossbeams. The beauty of this is that we will have two thusters on a very wide footprint, giving us excellent maneuverability when driven as a differential pair. The disadvantages are more complex mounting hardware and longer wire runs, though we might be able to play some tricks in solar-cruise mode with a small local leveling battery on each sides and direct connection to the folding array of 16 30-watt modules only 3 feet away from each unit.

Should be interesting, and if it works, it will let us forget the temporary gasoline outboard we’ve been planning on to give us an auxiliary during the initial post-rigging sea trials.

News Bits

Finally, in the random news department…

Thanks go this week to David Fichou (of DynEd International) for putting in a number of hours this week installing our phone system (donated by AsepCo). He chased down the wire and connectors, tested the units, installed the PABX, and ran wire all over the lab… now we have phones in my lair, electronics lab, the ship, crew nutrition facility, rejuvenation mezzanine, and Faun’s office.

It also looks like we’re going to be getting out on the water soon… between our listing in the Latitude 38 Crew List and our attendance at their party at the Corinthian Yacht Club in Tiburon last week, we now have about 8 yachts in our database of crewing options. At the very least, we’ll be doing some day sails on the Bay… gotta keep reminding ourselves why we’re working so hard!

Speaking of sailing, Faun and I are now 3 lessons into the Coast Guard Auxiliary’s Advanced Coastal Navigation course, which meets twice-weekly in Mountain View. I’m very impressed with the scope and depth of this… it’s actually requiring serious study. Lots of chart work, piloting, and navigation exercises… I highly recommend it to anyone planning on heading out on a boat.

Thanks to a pointer from Stig in response to an earlier report, my venerable old school bus now has a new owner, though we haven’t jumped through all the DMV hoops yet to make it legal. And the Fulmar is now safe in Dallas, ready for the next phase of the journey to her new home on the Turks and Caicos Islands.

Finally, today’s interesting link is www.amazon.com. This is a huge bookstore on the Web, with good prices, a decent user interface, and astonishing selection of over 1 million books. They’ll even store a profile and alert you when things of interest arrive… check it out! I’m just finishing up the Rama trilogy by Arthur C. Clarke and Gentry Lee during my relaxed moments… I’ll have to use Amazon for the next literary diversion.

Cheers from the lab!
Steve