navigator subscribe what is this? virtual console latest news home contact search
navigator1 boutique sponsors public speaking press room resources technomads microship adventure
navigator2 winnebiko volunteer sponsor behemoth winnebiko2
icon navigation album tech info bikelab why?

Notes from the Bikelab


Issue #7 -- 2/21/91

by Steven K. Roberts


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

IN THIS ISSUE:

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.



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)


AXOC (audio crosspoint output console)


AXIR (audio crosspoint input RUMP)


AXOR (audio crosspoint output RUMP)


AXIT (audio crosspoint input trailer)


AXOT (audio crosspoint output trailer)


(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.

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!!!