
---------------------- 
NOTES FROM THE BIKELAB 
Issue #7 -- 2/21/91
by Steven K. Roberts
----------------------

Copyright (C) 1991 by Steven K. Roberts.  All Rights Reserved.

	IN THIS ISSUE:
		The bike on TV next week in Silicon Valley
		BEHEMOTH's network architecture
			Control structure
			Serial matrix
			Audio matrix

	"Dinosaurs are transitory, but pizza is forever."
	     --	The summary of a discussion between Dave
		Berkstresser and myself about human- versus 
		petroleum-powered vehicles. 

News Flash
----------

	BEHEMOTH will be on TV in the Bay Area again next week.  If
	you'd like to see the bike (this time a technical overview),
	tune into the Silicon Valley Report on public television KTEH,
	channel 54, any of the following times:

		Thursday, 2/28 at 9:00 PM
		Friday, 3/1 at 7:30 PM
		Saturday, 3/2 at 5:30 PM

Onward...
---------

	The blur of late-nights and frenzied days since the last report
	in this series has yielded a hinged mezzanine in my RUMP, new
	wiring harness headers, a really nifty mounting tower for the
	RUMP control processor, progress on the new seat/steering
	system, and countless little nudges of recalcitrant hardware
	toward the Road.  The ROAD.  It's out there through all this,
	teasing me:  the love of my life, an endlessly tempting thing
	of infinite promise, motivation for obsessive around-the-clock
	hacking.  Still, after all these years, I get a thrill from
	browsing the atlas -- a thrill not unlike the chest-tightening
	excitement of Springtime's first beach day.  So many roads, so
	little time...

	And so it continues, day after day, night after night, every
	waking moment devoted to this machine, the countdown at once
	relentless, terrifying, and thrilling.  With increasing panic,
	I look around the lab and wonder what will become of all this
	STUFF when I leave in 21 weeks.  Will I just pedal away without
	looking back, like I did from Columbus a seeming lifetime ago?

	Ah well.  That's not today's problem.  Today I'm making the
	final decisions in the critical path to running the cable
	harness, and therein lies a tale.
	
BEHEMOTH's Network Architecture
-------------------------------

	As you may recall from issue #1 of this report, one of the
	major design objectives in this project is autonomy.  Here's
	the quote:

	"BEHEMOTH, whether moving or parked, must provide maximum
	possible autonomy in power generation, computation capability,
	file storage, communication, navigation, and maintainability --
	anywhere in the world, all controlled via a flexible graphic
	user interface..."

	That implies a lot.  In particular, it means that the system
	architecture has to be general enough to handle new
	technologies, on-the-road replacement of inadequate components
	with better ones that may communicate differently, the
	integration of widely diverse products into a single system,
	and overall control from a single user interface.  Considering
	that even communication protocols known as "standards" often
	lead to interfacing problems, this is quite a demanding design
	spec.

	After pondering the problem for a while, the solution became
	obvious:  crosspoint switching.  Traditional network
	architectures require all nodes to share some common
	characteristics and generally behave themselves; a crosspoint
	matrix doesn't care.  I can run events at multiple data rates
	simultaneously -- even DC or analog sensor data if required.
	(Audio, since it's so pervasive on the bike, gets its own
	matrix with a few special characteristics including
	gain-setting on every line.)

	This issue of "Notes from the Bikelab" is devoted entirely to
	on-board communications and crosspoint networking.  Let's start
	with the control architecture itself....

CONTROL STRUCTURE

	There are three processors aboard BEHEMOTH that spend most of
	their time collecting data, managing power, babysitting the
	network, and generally turning all the low-level control
	cranks.  These are FORTH 68HC11s from New Micros in Dallas
	(214-339-2204), delightful little 2x4" boards that are
	I/O-rich, draw little power, require no fancy external
	development system, and are eminently hackable.  (If you want
	to play with FORTH control, there's a good deal afoot at the
	moment -- one of their customers disappeared after ordering a
	run of custom boards, and they're unloading them at $65
	each...  with the FORTH CPU, an RS-232 port, standard HC11 I/O,
	and 32K of SRAM.  This is a deal that's hard to beat.  Call and
	ask for Gary Harden.)

	Anyway, there are three of these -- the bicycle, RUMP, and
	trailer control processors (BCP, RCP, and TCP).  The former is
	the boss, and has two dedicated serial lines that are hardwired
	to the console ports of the others.  The BCP's own console port
	is connected to the Macintosh Portable, which presents me with
	a graphic user interface implemented in HyperTalk.  The value
	of all this is that I can take the Mac offline to other
	applications without affecting the behavior of the control
	system, and if necessary I can have full access to the
	controllers via the RF data link or cellular modem... using the
	FORTH command line just like the Mac does.  The control
	environment is thus fairly independent of other processes, but
	normally appears in graphic form on the Mac screen.

	Each of the FORTH machines controls its local site completely,
	almost eliminating dedicated cabling and random logic.  They
	handle all power control of local resources via FET switching,
	collect data as required (security, power management,
	environmental, navigation, etc), and -- most important --
	handle the entire communication network.  What appears in the
	harness in addition to dedicated wiring for a few key systems,
	then, are the sacred serial lines between the BCP and its
	mates, eight uncommitted serial lines that can be used by
	anything, and eight audio long-lines that are likewise
	uncommitted and assigned by software as needed.  (Yes, I
	carefully considered fiber, which has enough bandwidth for
	everything...  but the power required to run the hardware quite
	outweighed the copper of the alternate approach.)

SERIAL MATRIX

	BEHEMOTH has a number of devices that communicate serially,
	scattered from one end to the other.  In most cases, I have a
	pretty good idea up front who will be talking to whom, but the
	possibilities are very diverse and there will inevitably be
	surprises.  Consider a sampling of RS-232-speaking
	machines....

	SPARCstation, Macintosh, main PC, little PC, even-littler PC,
	the three FORTH machines, GPS receiver, speech synthesizer,
	various packet TNCs, fax/modem, Icom 725 transceiver interface,
	the MIDI environment, a shock & vibration data-collection unit,
	a possible satcom system, external laptop, BP device
	programmer, PIC development station, digital oscilloscope, and
	who knows what else.  For starters.

	To accommodate all possibilities, there are three crosspoint
	FET matrices, one located adjacent to the FORTH engine in each
	site.  Implementing these was considerably simplified by the
	existence of the Mitel 8816 chip (408-249-2111 in San Jose;
	407-321-9880 in Florida; 619-276-3421 in San Diego).  This
	device is an 8x16 analog switch array originally made for
	telephone systems, and it joins a family that also includes
	8x4, 8x8, and 8x12 devices.  You can get it DIP or PLCC.

	The 8816 basically consists of the FET array, supported by an
	internal 7-to-128 decoder and a latch corresponding to each
	switch.  If you want to turn on a switch, just write the
	address and a set on/off bit, and voila:  an X line gets
	connected to a Y line and stays that way until you turn it off
	or reset the whole thing.

	I'm planning to run RS-232 levels through the matrix, just to
	keep connection of packaged systems easy and minimize the
	potential for noise pickup.  There's an argument for doing it
	all at TTL levels, but last time I tried that (in a smaller
	version of the matrix on the Winnebiko II) it was a real
	headache everytime I wanted to add something new.  We'll see.

	The nice thing about this general approach is that relatively
	unusual stuff -- like MIDI and the LAN link between the Ampro
	286 and the core module that runs the Private Eye -- can pass
	through the network along with everything else.  And any system
	can talk to any device, something that is particularly handy
	with the Audapter speech synthesizer that can be used (upon
	scheduling by the BCP) to verbally report status, read me the
	mail, talk to an intruder, call the police, have a maintenance
	dialogue with me via ham radio, etc.  The BCP will set up each
	speech event with a string that defines unique vocal parameters
	corresponding to each computer, so I'll immediately know who's
	talking.

	Speaking of speaking, let's move on to audio...

AUDIO MATRIX

	When I started specifying the matrix components for the audio
	crosspoint system, the number of devices astounded me.
	Ignoring the electronic details for a moment, the overall
	structure consists of 8 uncommitted audio bus lines running the
	length of the bike, passing through two boards at each site.
	One board can pipe any of 16 inputs to any bus; the other
	connects any bus to any of 16 outputs.  Amplifiers on the
	inputs and outputs allow matching to the very wide range of
	"sources" and "sinks" scattered around the bike.

	For your amusement, here's the current complete list of audio
	devices that are networked together via this system (input is
	defined as input to the network):

AXIC (audio crosspoint input console)
	Audapter speech synthesizer
	Mac speaker left
	Mac speaker right
	Covox speech board output
	Multimode TNC radio 1
	Multimode TNC radio 2
	Console 2-meter transceiver speaker
	Speaker-mic (plug-in)
	Main PC speaker output
	T1000 speaker output
	DTMF transceiver

AXOC (audio crosspoint output console)
	Voice Navigator II
	Mac Recorder
	Covox input
	Multimode TNC radio 1
	Multimode TNC radio 2
	Console 2-meter transceiver mic
	Speaker-mic (plug-in)
	DTMX transceiver

AXIR (audio crosspoint input RUMP)
	Casio CSM-1 MIDI left
	Casio CSM-1 MIDI right
	DX100 synth left
	DX100 synth right
	Setcom helmet mic
	Ambient mic
	Cassette out left
	Cassette out right
	Equalizer module left
	Equalizer module right
	HUD PC speaker
	CD player left
	CD player right
	AM-FM-SW left
	AM-FM-SW right

AXOR (audio crosspoint output RUMP)
	Yamaha stereo amp left
	Yamaha stereo amp right
	Small amp module left
	Small amp module right
	Helmet speaker left
	Helmet speaker right
	Cassette input left
	Cassette input right
	Equalizer module left
	Equalizer module right

AXIT (audio crosspoint input trailer)
	Icom 725 HF transceiver
	Yaesu 290 2-meter multimode transceiver
	Yaesu 790 70-cm multimode transceiver
	AEA ATV transceiver
	Audio filter module
	Cellular phone speaker
	TNC-1
	TNC-2
	Swintek wireless intercom
	CB
	Local microphone (commbay)

AXOT (audio crosspoint output trailer)
	Icom 725 HF transceiver
	Yaesu 290 2-meter multimode transceiver
	Yaesu 790 70-cm multimode transceiver
	AEA ATV transceiver
	Audio filter module
	Cellular phone mic
	TNC-1
	TNC-2
	Swintek wireless intercom
	CB
	Local speaker/headphone

	(Hope I'm not boring you with details -- enjoy them now,
	because after July 15 you'll be hearing instead about hot
	sweat, fleeting encounters, bizarre humans, strange events,
	technoid adventures on the road, campground hacking, ham radio
	exploits, and so on.  Wonder how the demographics of the
	nomadness alias will shift over time as some people bail out
	and others say, "ah, finally"?)

	Anyway, these crosspoint boards are currently being
	schematic-captured in OrCAD by Steve Sergeant, who is the audio
	wizard behind all the amplifier circuitry.  These will be the
	first components milled on the new Boardmaker from Instant
	Board Circuits, which will take the Gerber file from OrCAD and
	literally carve away unwanted copper to yield a double-sided
	board.  (IBC is at 415-883-1717 -- ask for Suzanne.)

	Steve's preliminary tests suggest that even though I'm not
	using differential line pairs on the bus, which would double
	the number ofcrosspoint boards, the 8816 chips and his
	TL074-based amplifiers can pass sufficient bandwidth for decent
	CD stereo (DC to 45 MHz in the 8816, according to specs --
	oughta be enough for my Blaupunkt speakers!).  Crosstalk and
	distortion are minimal, and I'll get to try out my new Amber
	3501 distortion and noise analyzer as soon as these go online.
	The only risk with the single-ended buses is noise pickup and
	crosstalk, and I'm running them shielded all the way to
	minimize the danger.  I'll keep you posted... this is one of
	those very central systems like power that has to work
	perfectly 24 hours a day.

OTHER CABLING ISSUES

	It would be nice if the matrix architecture could handle
	everything -- indeed, the next version of the bike (assuming I
	don't just give in to gravity and replace the wheels with a
	concrete foundation) may well have a single optical fiber and a
	power bus.  Designs like this are frought with trade-offs of
	complexity, power requirements, weight, hackability, cost,
	bandwidth, and interface requirements, and at the present state
	of the industry (given the constraints of a human- and
	solar-powered machine) this approach wins.

	But it doesn't handle everything.  There may be an ethernet
	link between the SPARCstation and the Mac (with MacX presenting
	Open Look on the Mac screen), unless the experts tell me that
	LocalTalk and regular RS-232-grade lines are adequate.  I've
	provided an extra waterproof LEMO coax connector at each site
	just in case.  (LEMO makes some amazing stuff, by the way -- if
	you need ultra reliable, environmentally sealed connectors
	ranging from power to RF to multipin, contact them for a
	catalog at 800-444-LEMO.)

	There are lots of other random interconnects.  The headmouse
	produces three low-level ultrasonic signals which have to make
	it from helmet to console.  Lighting controls, being essential
	safety equipment, produce nice simple DC levels from the switch
	box under the seat.  The handlebar keyboard gets preprocessed
	by a local Microchip PIC processor and squirted down a
	synchronous line to the BCP.  There's a phone line (other than
	the fully networked cellular) shared by various modems and the
	fax board, useful when I'm a guest in a home or motel room.
	There are various security and data collection sensors, the
	handlebar torque joystick, and a few other dedicated lines in
	the wiring harness -- plus the main power bus and a few antenna
	cables.  The dream of total generality has not yet been
	achieved.  But we're getting there, at least philosophically!

Closing Notes
-------------

	That's enough for now -- my drill itches, and I think it's time
	to go mount the stereo amplifier and the Motorola data
	transceiver on the RUMP floor.  There will be plenty of time
	for keypressing Out There.

	In the meantime, watch out for a new danger associated with the
	corporate lifestyle.  It affects those who share rides to work,
	and manifests itself as sharp pains in the tips of the toes.
	It's... the dreaded Carpool Toenail Syndrome.

	Cheers from the bikelab!!!

		Steven K. Roberts 
		Nomadic Research Labs 
		P.O. Box 2390 
		Santa Cruz, CA 95063

		wordy@bikelab.Sun.com (primary internet)
		wordy@cup.portal.com
		GEnie, MCI, or AOL:  wordy (GEnie preferred)

