Art without engineering is dreaming;
Engineering without art is calculating.

Steven K. Roberts, N4RVE

Bikelab Report #14 – Post-Nomadic Stress Disorder

by Steven K. Roberts — Silicon Valley, California
December 31, 1991

“The difference between art and work is that work has a deadline.”
—David Berkstresser

Post-Nomadic Stress Disorder… and Quest for Humans

sun-bikelab-1Damn, I hadn’t anticipated this… but I should have. Working obsessively for a few years on BEHEMOTH and then abruptly relocating it to the shores of Lake Michigan for a shared adventure of technoid romance with a winsome friend, I set the stage for what one might, in another context, call anticlimax. In the two months since returning to Silicon Valley and issuing Bikelab Report #13, life has been a potent reminder of all that I DON’T want life to be: stress, overload, deadlines, lack of adventure, and a pervasive sense of panic at the impossible complexity of this project. Even with help from a number of friends and the powerful urge to GET ON WITH IT, there is an almost helpless sense of dealing with something too big for one person to manage. It’s not just the bike: I have a mothership to prepare, two article deadlines, a speaking business to launch, books to write, relationships to build… madness, all of it. Yet, when I consider the alternatives… maybe it’s not so bad after all. Technically, I suppose I’m homeless and unemployed — but I’ve never been so busy (or had so much fun) in my life!

You know, all I really wanted, that innocent day in the Spring of 1983 when this idea first struck me, was to escape Ohio suburbia and hit the road for a grand adventure. It was an adventure alright, more than I had ever dared imagine, but somewhere during 17,000 miles of pedaling and twice that in other vehicles it turned into a mini-industry (however nomadic and eccentric it may be). In an ironic twist, I’m now more stressed than I would ever have become had I chosen a life of honest work.

All of which has something to do with this article. I’ve issued various calls for help to the net before, always finding interesting people popping into my mailbox for weeks thereafter. I already get too much email, but the network is my lifeline (do I complain about getting too much oxygen? Too much food? Too many ideas?). Recently, I posted a short form of a “nomadic partner wanted” ad to misc.jobs.offered, sparking a flame war with the kind of nonstandard prose you might expect in a case like this — rhapsodizing about sharing a life fueled by passion, looking for someone attractive enough for a media-intensive lifestyle, strong enough to pedal a heavily loaded bicycle, and so on. This yielded a number of flames couched in equal employment opportunity jargon, not to mention moral outrage at the obvious blend of work and play that seems, in this post-Thomas/Hill era, somehow incorrect to self-appointed arbiters of public morality (the net.police). Fortunately, the majority of posters in the skirmish were in strong support of this venture, pointing out not only the irrelevance of strict EEO law in a non-employment partnership but also the genuine appropriateness of the requirements. This is not exactly a normal gig, appearance and strength DO matter, and the whole thing is half personal anyway.

So before giving you the update on bike tech and related matters, I want to continue this quest and also launch a few others. Nomadic Research Labs is looking for help — not only full-time on-the-road companion(s) but also with specific hardware, software, and construction projects.

First, the nomads. I’ve had the dream over the years of putting together a nomadic community, a tribe of network-linked freelancers who move freely in physical space as whim, weather, and clients dictate. If this seems risky in these economically troubled times, remember that your real security is not what’s in your bank account, but what’s in your head. Skills are highly portable, and many of them can be wielded entirely via networks, phones, fax, pagers, satellites, and so on. If you are a wizard in some field, you will be welcome anywhere — yet you can maintain the illusion of stability via methods that are now very familiar.

I originally assumed we’d all be on bicycles, but that’s an unreasonable constraint. My current image is much more general: a group of varying size, sharing certain basic resources (home base site, gateways and file servers, lab tools, and so on). The default mode is travel, but there’s no expectation that we’d always be in a group (with one exception, to be noted in a moment).

Technology has developed enough in the last few years that this idea, once rather fanciful, is now quite realistic. Virtually any information-based business can be operated from the road — there’s a “bicycle” over there behind me snarled in a mad tangle of umbilici, and when next it rolls it will carry a 16-megabyte color SPARCstation with a half-gig of disk, Macintosh permanently active as a GUI, mapping system driven by GPS satnav, DOS machine with helmet-mounted display, ham station, cellular phone with high-speed modem and fax, speech I/O, audio network, and much more — all weatherproof and running on solar power. Given all that on a bicycle (however extreme), it is clearly possible to scale it down to something reasonable and provide people with tools robust enough to do business on the road while remaining connected. Think of BEHEMOTH not as a lifestyle prototype (it’s WAY too heavy and complex), but as a caricature of nomadic system integration… something that is increasingly important to the business community at large. The keynote address at COMDEX this year pointed to “field computing” as the next major trend, and it seems that all system vendors are trying to carve out some spectrum and get in bed with the RF wizards… it all points to one thing: getting away from your desk without simultaneously disappearing from Dataspace.

I have come to believe that with the right organization and system administration, a vaporous community of arbitrary size can share the resources and overhead that make networked technomadic freelancing effective for everyone involved. If you see yourself fitting into this, let me know. A few specific roles and business ideas include:

  • Productizing spinoffs from BEHEMOTH and other work.
  • Writing, photography, art, and other creative efforts.
  • Home base management for the whole enterprise.
  • Speaking, consulting, training, and related professional gigs.
  • Maintenance and system administration for the group.

There are so many angles here that it’s dizzying. I don’t want to RUN this, but I’ll sure help make it go if a critical mass of interesting people manifest themselves. And while I’m at it, I’m looking for a home base, ASAP. Let me know if you have room for mothership parking and a permanent lab setup. Somewhere within a few hundred miles of Silicon Valley is preferred, but I’m open to other possibilities.

Now for that exception, noted earlier. I need a full-time assistant on the road to insulate me somewhat from the realities of the world, help at trade shows and speaking gigs, work with me on all projects, do correspondence, share the adventure, assist with the extensive logistics and overhead of travel, manage planning, share driving, run the mothership operation when I’m on the bike or doing a gig marathon, etc. This is a special, close, complex relationship, and involves too much detail and too many issues for further discussion here. But if you are interested in a complete lifestyle change coupled with a bizarre panoply of experiences and professional connections, send me email — and soon. There are a couple of good prospects already, and time is short.

I mentioned at the start of this article that there are also some projects I need help with. This whole undertaking has been possible largely because of the 45 or so people who, over the years, have donated their personal time to helping with various bike tasks. Since my return from the midwest, Dan Pritchett, Bob Gahl, Joe Dunn, and Michael Grant (all of Sun Microsystems) have put in significant time, with David (Zonker) Harris, Mike Perry, and Steve Sergeant participating heavily as well. Thanks!

There’s a lot more to do in the next 12 weeks, and I can’t resist listing a few specific tasks to see if I get any nibbles here. At this late hour, I’m not looking for general “I can help with software” responses — just specifics:

  • Writing and testing a special serial xcmd that links HyperTalk on the Mac to the FORTH boards (a bit of handshaking for downloads) and provides a clean development environment (easy access to DA editor, find line number from error trap, etc.).
  • Welding a hinged steel secure box to go between the van seats in the mother ship. I need a place to keep the remote bike console, ham equipment, CD, and other stuff while in petroleum mode.
  • Building cabinetry for the trailer — work surfaces, storage areas, and so on for the mobile bikelab. This is urgent, and is a project large enough to cost me real $ or barter… know any hungry cabinetmakers in Silicon Valley?
  • SPARC-to-Mac uucp link, via RS-232 since there’s no small ethernet board for the Mac Portable (hoping for upgrade to PowerBook 170 board, but can’t plan on that yet), and since an AppleTalk SBUS card takes up a slot I can’t spare in the SPARC 1+ board (color LCD controller takes two; VideoPix frame grabber wants one.
  • Full analysis of HF antenna system to determine need for balun, RF choke, or different length of feedline (funny SWR under some conditions).
  • Testing and integration of mapping software and CDROM.
  • Construction and test of low-noise volume & tone control board for main power amps.
  • Mechanical fine-tuning of disk brake system
  • Design and assembly of surge brake system on trailer, using Magura hydraulics. Hitch design left room for this.
  • On-site EXPERIENCED tech help for a variety of small hardware projects, cabling, board stuffing, debugging, and so on.
  • Solar power system and local battery manager for mother ship.
  • Construction of a few regulator boards using Power Trends switcher parts and FETs.
  • At the risk of being too general: etcetera!

There’s little or no money in this, but there are many other benefits, including fun, learning curves, making contacts among the community of amazing people who have become involved here, and doing something technical because it’s interesting — not because it’s your job. Remember <sigh> the hobbyist era? It’s still alive in the bikelab, running on strong tea, friendship, and obtanium!

San Diego and Seattle travel in Jan-Feb

Some time ago I promised you that I’d announce public appearances and firm travel plans here. There are many people on the net that I’d like to meet, and I can’t always be counted on to track everyone down when I’m passing through an area. Now that I’m officially (whatever that means) going on a speaking tour with BEHEMOTH, I’m very much in the mood for scheduling talks with user groups, on campuses, or at companies. Or wherever. My speakers bureau (Keynote Speakers in Palo Alto) handles the formal, big-league kinds of gigs, but nothing prevents me from arranging events on the side… and I’m often in the mood for a party and/or a place to stay when visiting an otherwise unfamiliar city.

Here’s the schedule of known events during the next two months:

On January 10, I head to Los Angeles in the mothership to visit my base office in El Segundo enroute to San Diego. Time will probably not permit additional LA visits during that weekend. I then arrive in San Diego Sunday, do a day of local media Monday, and display the bike for two days at the San Diego Electronics Show on Jan 14-15. I then plan to spend the next two days visiting Qualcomm and RDI, and possibly other companies. This, as well as the weekend, is currently unscheduled, and I’m open to suggestions (including the beach!). I expect to head back to Silicon Valley on Monday.

A month later, I hit the road again — this time north to Seattle. With a stop in Portland and Vancouver along the way to see OrCAD, Sharp, Larsen, and others, I’ll arrive in Seattle on February 22. Other than informal visits to Traveling Software and Icom, the first three days of the week following (Feb 24-26) are unscheduled; after that is an appearance at the Seattle Bike Expo Friday and Saturday. Sunday is an all-day ride around Bainbridge Island, then I’ll probably head back south on Monday.

Finally, I think I’m showing BEHEMOTH at Idea ’92 in San Jose on April 14-16, but I don’t know further details. I expect to leave directly from there and hit the Dayton Hamvention, then kill a few weeks (like, maybe, actually RIDE the bike??? what a concept…) enroute to Interop Spring in DC. Plans here are vague…

I hope to meet lots of interesting denizens of Dataspace while out prowling physical space!

Bike status: SPARC update and crosspoint switches

Oh yes. These bikelab reports are ostensibly about the bike project, aren’t they? If that’s all you were looking for when you got on the internet alias, wandered into NOMAD on GEnie, or downloaded this from any of the various archive sites — sorry about that. Turns out, in practice, that despite all the technology on BEHEMOTH the real issues persist in being human ones, and that can distract me terribly from programmable gate arrays and hydraulic braking systems. But while much of my bandwidth since returning from the midwest has been soaked up in biz, there has been some very interesting progress on the monster itself.

First, the long-discussed crosspoint switch matrices have come online, at least in the console. The design of this was discussed in detail in issue #7 of these reports, so I won’t repeat it, but there are some updates.

First, the serial system. I posted a request for help on sci.electronics, mentioning that I wanted to take a variety of RS-232 devices and link them all through a Mitel 8816 chip powered by +5 and -5 volts. This requires me to constrain the swing of the transmit lines within that range, and I needed an easy way to do that.

Fascinating thing about posting anything to usenet. The range of opinions out there is staggering — from a variety of conflicting but well-informed suggestions to total lunacy. I was advised to use zeners, dividers, individual drivers, TTL levels, RS-422, RS-423, RS- 449, op-amps, diodes to Vdd and Vss, a dedicated micro, hacked drivers on every subsystem, optical fiber, and ethernet. After staring at all this for a while, I took Dave Wright’s suggestion and used a 3K series resistor on each transmit line, feeding the network via a pair of back-to-back 3.6-volt zeners to ground. This constrains the swing within the supply range and still delivers the required current through worst-case 160 ohm network resistance to the RS- 232 receivers without dramatically raising supply current at the transmitters. What a pain… but it works. (Before flaming, remember that issues include dealing with a wide variety of existing systems that aren’t necessarily all turned on at once, not to mention the power problems of adding true network overhead.)

Supply, incidentally, is a Maxim MAX-660, which takes the 5V from the bicycle control processor’s backplane (in turn, from a switcher off main bike bus) and inverts it to -5 using a couple of 150 μF electrolytics. Much easier to use than the ones that require inductor-hacking… though it is currently getting loaded to -4.53 at only 62 mA so there’s another puzzle to solve.

Initial testing in FORTH got the serial crosspoint running fine — there’s now one local path in each site and three “longlines” paths, any of which may simultaneously carry traffic between any combination of 16 serial devices in the console and 8 each in RUMP and trailer. The FORTH code, largely created by Mike Perry, responds to a request such as “SPEECH MAC LINK” by finding and acquiring the first available pair, updating an array reflecting the status of all crosspoints, and turning on the appropriate FETs in the 8816 chips. At that point, the Macintosh and Audapter synthesizer are connected as cleanly as if you had just plugged a serial cable between them.

auxbar-closeAudio networking is architecturally much the same, but is complicated by one annoying characteristic of audio: it’s analog. This means we suddenly care about distortion, noise, and crosstalk, and has resulted in three custom printed circuit boards stuffed with 8 TL074 quad op-amps each, as well as a pair of 8816s and a couple hundred discretes. (Credits: Steve Sergeant did analog design, Bob Lockhart did CAD work, Mesa Reprographics did films, Sun Circuits did boards, Joe Dunn stuffed them, and I bolted ’em down and started testing.) Yes, next generation I’ll go with codecs and all-digital networking — I’ve learned!

But these work amazingly well, and Steve determined with the Amber noise and distortion analyzer that trash is at -80 db, crosstalk worst case at about -50 db. This is clean enough for acceptable road use of the stereo while also handling speech, ham radio, cellular phone, and modem tones — we just have a few little problems to take care of. Like the noise generated from operation of the Sony CD player… turns out that its power “ground” and audio “ground” are different things entirely, and work fine on floating (battery) supply but poorly when integrated <sigh>. We’ll try AC coupling… or maybe just switch players (I want one that’s more robust anyway).

auxbar-edgeDetails, endless details. Other than that, the audio crosspoint is way cool, and the host (Hypertalk eventually; at the moment Bill Muench’s BHOST on a PC) can connect anything to anything by issuing simple textual commands to FORTH (CD-LEFT AMP-LEFT CONNECT), whereupon Mike Perry’s code manages the matrix and assigns buses. (This extends to the mother ship with a simple Y cable at the trailer hitch, by the way.) It turns out that mixing works well — a plus, since a lot of low-priority occasional audio sources like computer speakers and warning beeps can all be dumped into one bus and piped to a small speaker, and synthesized status updates can interrupt music gracefully without having to own the channel and startle me from an adagio-induced reverie.

A single bus cannot cleanly feed multiple output stages, though, which might make phone patches and the like difficult. Problem is in the nature of the op-amps: there is an “input noise” that’s normally nullified by their essential op-ampness, but connecting two inputs together lets them amplify each other until the resulting hiss is very significant. There are all sorts of strange surprises like this in the analog world, which is why analog engineers will always be able to find work. As for me, I just want to get this all done so I can view the world digitally, the way it was ~meant~ to be! 😉

Speaking of things digital, there has been a tremendous amount of work lately on the wide-area networking tools — most notably, the SPARCstation. After much deliberation, I’ve decided to remove the console’s 286 DOS machine, excise the VGA display, and replace them with the SPARC and a Sharp 10.4-inch active-matrix color LCD (the DOS system, a rugged Ampro Little Board 286, will go into the mother ship as a CAD workstation — and the SPARC can emulate DOS for Windows applications and OrCAD).

One of the color LCDs is running on a machine here at Sun, and it’s seriously beautiful. I’m trying to get a couple of Conner’s new 212-Megabyte 1″ high drives (identical package to the pair of 40’s in there now), and, well, if all goes as planned we’ll have a compute engine on board that can blaze through 624,000 instructions for the passage of each rear-wheel spoke at my normal cruising speed of 9 mph. Or, you can think of it as 6.4 billion instructions per mile — and that’s just this one machine. Crank up the Mac (hopefully becoming a PowerBook 170 board instead of the current Portable), the other PC behind the seat, all the FORTH boards and PICs and about 35 embedded processors in products and… and the numbers become so thoroughly ridiculous that it makes the head swim. How many transistors, I wonder?

Phew. Where was I? Ah — the SPARC. Anyway, what we’re trying to do, once this is physically installed, is set up the right handlebar keyboard (based on the Infogrip BAT) with three simultaneous interfaces to Mac, SPARC, and DOS machines, steering them via commands from the chord keyboard on my left hand to the BCP. The data stream can be piped through the Ampro if I want to run the PRD+ macro software, appearing to Mac or SPARC as a super-fast typist coming in through hacked keyboard drivers. This all gets very convoluted, but should make sense in practice.

Mail continues to be one of the main applications for all this (hardly justifying a color screen, of course — that will pay for its amperes when I’m doing maps, CAD, and video frame-grabbing). We’ve been puzzling over the best approach for months and this is still not cast in concrete, but the way it looks now is that the SPARC will wake up once or twice a day, request the CellBlazer via the serial crosspoint system, and have the BCP fire up that, the Celjack, and the cellular phone. It will then make a call to my home-base workstation, responsible for deciding which pieces of mail get held for the uucp call and which get piped immediately to the bike via the Qualcomm satellite terminal. Once that mail transfer is done, the bike will call MCI and GEnie, inhaling the day’s mail and rewriting headers to make it all look like internet traffic in the same mail spool environment.

At that point, Michael Grant’s custom sendmail hack will somehow notify the Mac (via a flag in the BCP, probably) that mail is waiting, whereupon the BCP will shut down the cellular link and establish a local uucp connection between SPARC and Mac (RS-232 for this — I still haven’t found an easy way to do ethernet or AppleTalk between the SPARC and the Mac Portable since ethernet requires a clunky SCSI interface on the Mac and AppleTalk eats an SBUS slot on the SPARC…. selecting a component gruppo for a modern bicycle just isn’t as easy as it used to be….). At this point, the SPARC acts like a mail server to Eudora in the Mac, who inhales all the recent traffic and presents it in a single mail tool that also, through a different path, acquires satellite traffic. Presumably, this will all get properly sorted upon reply so that outgoing messages get queued for their appropriate destinations — via internet gateways in the case of MCI, GEnie, CIS, and anything reachable directly or via Dasnet. Multiple mail accounts will exist on the SPARC to accommodate other travelers, other moods.

Ah, connectivity. It wasn’t so many miles ago that I was very pleased to slip a Radio Shack acoustic coupler onto a pay phone and log on from a campground at 300 baud with my trusty 32K Model 100…. Now I hear that many pay phones in Tokyo have ISDN jacks on them: you can download your favorite font to make catching up on email as aesthetically pleasing as possible, while including voicemail or image attachments on your letters!

There’s a lot more going on here — countless little parallel projects getting nudged along incrementally. As I write, Dave Harris is over there working on serial interface and power control for the Trimble GPS receiver, which should be a major source of fun in the near term and a key link in security and mapping systems a few months from now. I’m getting bids on mothership cabinetry, and making lists that attempt to reduce this entire mobile bikelab project to the level of CDT’s (clearly-defined tasks). And time passes inexorably — something I can’t help but notice as I spend yet another New Year’s Eve in a strange place, hacking away madly in the name of adventure…

Happy New Year!

Steven K. Roberts