Site icon Nomadic Research Labs

Bikelab Report #7 – BEHEMOTH Network Architecture

Steve

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

Bikelab Notes #7
by Steven K. Roberts
February 21, 1991

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

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, delightful little 2×4″ boards that are I/O-rich, draw little power, require no fancy external development system, and are eminently hackable.

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

Zonker Harris wiring Lemo connectors in the BEHEMOTH console

Serial Crosspoint 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. This device is an 8×16 analog switch array originally made for telephone systems, and it joins a family that also includes 8×4, 8×8, and 8×12 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 every time 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 Crosspoint 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.

This is the Audio Crossbar (auxbar) network on BEHEMOTH (later photo).

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 Sergeant testing audio crossbar distortion using the Amber analyzer

Steve’s preliminary tests suggest that even though I’m not using differential line pairs on the bus, which would double the number of crosspoint 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 fraught 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.

There are lots of other random interconnects. The head mouse 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!

Exit mobile version