Steven K. Roberts
UCSD – San Diego
Microship Status 2/2/94
Control Network Update
First, the Microship Control Network continues to occupy center stage, as far as effort is concerned. We have completely eliminated the noisy RJ-11 phone wiring that I was hoping to get away with and I’ve made a braided cable of three twisted pairs that so far supports five nodes. Initial tests are very encouraging… last night I wrote a test program (rather unimaginatively called SCANLOOP), and it successively polls the five New Micros FORTH boards currently connected (Serial, Audio, Video, Battery, and Distrib). After making the Easy-A connection to each, it issues the FORTH word “HEY,” which simply causes the chosen board to reply with something on the order of “I am the AXBAR!” Works fine, and ran all night.
As I noted before, this does not yet support multitasking, but a couple of interesting alternatives are under development. I’ll report more on that soon… but it looks like each of these little boards will be running a multitasker that allows both the application and the interpreter to operate independently, with serial data interrupting the processor and subsequently being added into a ring buffer if the Easy-A selection is valid. The good news at the moment is that we appear to have stable communications — the current cable is about 25 feet long and it’s even running reliably without termination.
By the way, I’ve just ordered a set of three level-converter boards to allow the RS-422 console on a node board to converse with a standard RS-232 terminal. This will be immensely useful in the lab, where 7 project teams are competing for time on the hub console. One converter will become part of the boat, allowing emergency bypass of the hub in case of hardware failure.
Now that we have established communications (though still not robust — the networking code disappears on power cycles, since I haven’t yet had much luck injecting it into the 68HC11’s internal EEPROM), the students working on control projects are getting more into the hardware. Nobody has actually interfaced anything to a FORTH board yet, but that should be happening in a few days…
Control Project Status Notes
AuXBAR: The audio crossbar team (Jason Corley and Isaac Chu) has been making excellent progress on developing the central crosspoint data structure, which is also being used by the Serial and Video groups. Jason has demonstrated FORTH tools to make and break connections, find the first free bus, and clear the array; Isaac is writing some of the high-level tools that interact with the host. They’re planning to interface the audio boards this weekend, pending availability of ribbon cable and headers.
SeXBAR: The serial crossbar team (Dan Sebald and Jeff Simon) is focusing on two areas. Dan is working on the board itself, with four Mitel 8816s, I/O headers for 16 control lines and 32 pairs of serial lines, and an array of “level constrictors” that constrain incoming RS-232 signals to a +/- 5V range that fits within the supply limits of the crosspoint chip. This strategy worked well on BEHEMOTH — we just use back-to-back 4.3V zeners to ground, with a 1.2K input resistor to limit the current. Meanwhile, Jeff is thinking about some of the networking issues that go beyond the crosspoint itself… this is the board that will allow the hub to select its own console.
ViXBAR: Delon Levy has selected the Mitel 88V32 for this, which is architecturally similar to the 8816 but has a number of internal ground paths to minimize crosstalk at video frequencies. Each chip (PLCC package) is a 4×8 matrix; three of them will support 16 inputs and 8 outputs with any four connections active at a time. He is currently researching distribution amplifiers to allow one source to drive multiple loads, and we’re awaiting parts for board fabrication.
HUB: The hub team (Michael Bream and Chris Tuft) has been involved in the whole issue of bringing the network online, and has not yet begun the actual application software. Much of this work in development tools and networking, however, is critical to subsequent efforts, so this is all essential groundwork. Michael has also configured and patched most of the FORTH boards, with 11 now ready for network connection.
ULTRASONIC RANGING: Carl Mascarenas has reverse-engineered the LED display drive on the ranging system, and is writing the FORTH code to convert it to BCD.
GPS/NAV: Henry Xia is in the FORTH learning curve, and I packaged a 2-channel serial card and a FORTH board on an aluminum panel to support the GPS. He has also decoded the NMEA sentences and is ready to start on the interface software — as I write this, he’s in there working on the serial board software.
SOLAR MANAGER: Mohammed Sarhadi has performed initial tests of an LM10-based current measurement circuit, designed to produce an output proportional to the voltage drop across a .1 ohm resistor in the ground leg of each photovoltaic module. He will also be looking at the charge bus voltage with a divider, and array temperature with an LM335. He’s currently investigating analog multiplexers for routing all this into the 68HC11 8-channel A/D converter.
Other Project Updates
Jeremy Heath is building a clamping system to mount a 2-meter J-Pole antenna on the roof of the engineering building without drilling any holes (being in an engineering building without antennas has been rather embarrassing!). This will let us get a packet radio station going, start monitoring local ham repeaters, and — with a trip to the roof to swap antennas — hobnob on the HF nets. It will be the key to firing up a packet-linked manpack GPS system.
Len Wanger at the San Diego Supercomputer Center has outdone himself… he has created three images of the virtual Microship integrated into real scenes! Check these out via Mosaic on our World Wide Web server.
The Ampro 286 computer that will be the dedicated user interface to the control system has been receiving attention from Frank Araullo, Dan Yang, and me this past week… but we don’t have it running yet. Latest suspicion is that we’ve been borrowing the wrong kind of monitor — we need VGA. Also, a Sharp color TFT 6″ diagonal LCD should be coming soon… and it will also display video from the crosspoint switch.
Speaking of computers, my SPARCstation 1+ is back. This was donated by Sun a couple of years ago, and has been on loan to my manager’s husband for a while. Now that it’s here, the next step is to get it on the network along with everything else. The Information Networking Team is meeting here Sunday to discuss all the Ethernet issues, as well as the organization of our Mosaic page.
Robinson-Nugent is no longer in the business of making Quick-Connect IDC prototyping boards, alas, so I’m trying to track down contacts at Vero. This is a low-profile alternative to wirewrap that will significantly speed custom logic board fabrication. The Serial and Video groups are doing handwiring on perfboard…
The lab is now much more open and accessible — we’ve upended the cockpit mockup, cleaned the worksurfaces, added project boxes, and generally attempted to fight off creeping entropy. As the ShipNet comes online, we’ll be spreading it all around the lab to allow many projects to coexist.
Finally, there’s now a 3×5 cardfile in the lab, clearly labeled “CDT Box.” Inside, there are cards for jobs that needs to be done (but not jobs that would justify full-scale student projects!). I’ve had dozens of generous volunteer help offers… now we have a collection of things that need to be done. If you want to contribute a bit of time to the Microship project, please wander by and browse the box…
Those are the headlines… back to it!
Microship Status 2/6/94
- Ampro Pc Is Up
- AuXBAR INTERFACE CIRCUITRY
- Forth Network LEDs
- Electronics Flea Market
- SeXBAR FABRICATION AND BEHEMOTH CANNIBALIZATION
- INTERNAL FRAME STRUCTURE
- Mosaic Online Project Documents
- CU-SeeMe AND GLOBAL SCHOOLHOUSE PROJECT
- Book Projects
- Nrl Base Office Needed!
Life is a blur of meetings, interrupts, hardware projects, business issues, and the impossibly prolific spontaneous generation of items on TO-DO list. This report will reflect all that by taking the form of a whirlwind update…
First, the Ampro PC is working! As of the last report, we were still scratching our heads, wondering why there was no display. A conversation with the sponsor revealed that we were using the wrong kind of monitor (it needs VGA with DB-15 cable), and borrowing the correct one brought it up immediately. Unfortunately, we’re working from 5.25-inch floppy and now need an IDE hard drive for the development system since the one from the junk box doesn’t seem to work. Frank Araullo has a line on a used 40 meg unit, and we’ll be trying it this week. Note that both the monitor and the drive are temporary — the ship will carry a Sharp color TFT LCD and a PCMCIA flash mass storage system for minimal power and maximal reliability.
This weekend I worked with Jason Corley on the Audio Crossbar system, installing zener diodes on the analog boards to allow the 8816 chips to run safely from the +/- 12V op amp supply, populating the boards with chips and a few missing caps, making the split ribbon cable, and building the interface logic on the processor board. This last was the most time-consuming, and I finished it today from Jason’s schematic. We’re now ready to begin initial tests of the AuXBAR — the first of the control network projects to be interfaced and brought online.
By the way, I’m adding an LED to each of the 15 FORTH boards on the network, driven by a transistor connected to port A, bit 3. This is what enables the RS-422 drivers onto the net, and the LED will show communications activity. This should let us see at a glance the operation of the protocol, as well as spot a board that’s hogging the bus or is never selected.
Agnes and I went to the monthly ham/electronics/computer flea market at the Santee Drive-In Saturday morning. While paltry by Silicon Valley standards, it did provide a nice alternative to the other local parts resources. I spent about $40 on tools, wire terminals, heat shrink, diodes, and other odds ‘n ends. I’ve been spoiled by doing the bike project in the Bay Area, with Halted and other resources available daily. Now I’ve been reduced to mail order, and we’re awaiting an $85 Digi-Key shipment that has a few projects on hold.
The serial crossbar fabrication was begun by Dan Sebald, using point-to-point wiring on perfboard. This is way ugly (through no fault of his), and since this is a board that is critical and likely to be subjected to considerable handling for the next decade I’ve decided to commit my first act of BEHEMOTH cannibalization. An R-N Quick-Connect prototyping board is in the WASU, unused, carrying the trailer control processor that hasn’t seen power in about a year. It’s just too useful a resource to leave in that dormant state, so we’ll extract it and slice off a section for SeXBAR use.
An encouraging meeting took place today with Robb Walker and the internal frame structure team (TJ Tyler and Jeff Klompus). TJ and Jeff presented Robb with the TAD (toothpick-aided design) model of the frame, and they spent about an hour discussing the structural requirements of this critical component. As you may know from earlier discussion, we have decided to separately construct the hull and frame — the former to handle flotation and hydrostatic loads, the latter to support the dynamic torsional loads of trailering, sail forces, outrigger attachment, and so on. Final assembly will permanently integrate the two. There are transverse planes in the frame coincident with bulkheads, and these are where the masts and outriggers attach. Anyway, TJ and Jeff are now well into the Mentat (Finite Element Modeling) learning curve, and the meeting with Robb confirmed that they are on the right conceptual track. We should see some interesting results here by the end of the quarter.
I also met today with John Studarus and Frank Araullo, who are both involved in the electronic publishing aspects of all this. We are working on bringing the WWW and Gopher servers up to date, with some big plans for a fully integrated hypertext documentation system as well as the requisite multimedia demos including images, sound, and film clips. Frank is working on linking the Microship Control System diagram to a library of documents that will allow the user to simply click on any item of interest and see a description of its function and current status. We’re also trying to decide whether to place the full ongoing library of these status reports on the server, since the Nomadness Notes are published so infrequently that they hardly qualify as “updates.”
Speaking of interesting networking tools, I accompanied Jean Polly on Friday to Jefferson Junior High in Oceanside. This is where Yvonne Marie Andres is using Cu-SeeMe to develop the Global Schoolhouse Project — kids around the world linked via live multichannel video conferencing. It’s quite impressive to see a Mac screen with a half-dozen active monochrome video windows from various sites logged onto a reflector, and we spoke with my contact at NSF about their funding a Video Spigot for the Microship lab to allow the schools to periodically look in on the activities here. This will of course move to the water, with the conferencing tools (albeit bandwidth hobbled) augmenting our environmental data blocks, video still frames, and text updates.
Other text projects are moving ahead as well. I’ve established a relationship with a new literary agent to represent me on the various projects, and Bobbi Smith has completed the edit of Miles With Maggie, the sequel to Computing Across America. This is now posted on the Mosaic (WWW) server, although the Gopher and FTP sites still have ancient versions.
Finally, I’m putting out the word with some urgency that I’m in need of a new base-office manager. Barbara Chase, who has quite capably managed NRL for two or three years, is moving on to other projects and a new house, and we urgently need someone, reasonably stable and preferably near San Diego, to take on the home-based job of running this business. This will include mail-order, media management, photo archiving, daily email contact, and the myriad tasks that hold a complex enterprise together. If you know of anyone net-literate, savvy in the ways of business and publishing, generally available during business hours, and free to work part-time on a percentage basis instead of fixed salary, please let me know. This may be expanded to include coverage of other freelancers who may travel with me (the flotilla), as well as a commercial net-linked home-base support service for technomads.
Cheers from the lab…
Microship Status 2/9/94
Today’s mail brought a pair of 68HC24 port-replacement units from New Micros, as well as four PLCC sockets for those and the Mitel video chips. The PRU’s are necessary on some of the controller boards to add two parallel ports — we installed one leftover from the Winnebiko II on the Audio Crossbar and it simplified things tremendously.
Also today, I arranged for shipment of the Sharp LQ6NC01 NTSC-compatible color LCD panel. This 6″ diagonal color screen will be the display for the Ampro PC (the control system console), as well as the helm video monitor.
And in the email-basket, a self-extracting archive of 37 files arrived from Bill Muench — his FORTH multitasker, comm tools, test files, and downloader scripts! More learning curves ahead, as soon as I deal with….
The Heartbreak Of Datacomm
Yes, once again, serial communications has ruined an evening. I worked with Henry Xia for about three hours tonight, trying to get the 2-channel serial board to behave on the nav system controller. It uses one of those complex do-all ACIA chips from Rockwell, and the first hurdle was the learning curve — after which we got it receiving reliably from a nearby laptop.
Transmit is something else again, and even though we can make it echo received characters (proving that all drivers and cabling are good) and even though we can obviously talk to the chip… we can’t seem to make it actually transmit any characters from the host. Maddening. I hate computers. However…
THE AuXBAR IS ALIVE!
I mentioned last night that the Audio Crossbar was on the verge of going online, and after mounting all the boards on a substrate today and whipping up a power connector I handed it over to Jason. Hesitantly, he sent it a RESET and I saw the pulse on the logic probe; emboldened, he sent a CONNECT command and voila! The CD player’s output blared out of a little amplified speaker! Another command, and the music was replaced by the NOAA weather report from a small scanner. All quite wonderful. Now we need some textual front-end tools that let us talk to it by human-readable device names instead of cryptic channel numbers, more audio devices for testing, some work on noise minimization, fine-tuning to normalize signal levels within the network, and bus cabling to link the two 16×16 boards.
Steve Sergeant, an audio engineer with Sony, designed the analog parts of these boards during the BEHEMOTH epoch, and he has offered to consult on related issues if people route their questions through me. Steve sent a note about noise and interference to Frank (the noise czar) — since this is an issue that will affect everyone on the project, I repeat his comments here…
NOISE NOTES (by Steve Sergeant)
In my experience, noise control has a lot more to do with grounding, proximity, and power supply decoupling than it does with shielding. The simplest statement about it I can make is to think about your system in terms of where the currents flow in the power and ground systems, always keeping in mind Kirchoff’s current law. In other words, if current flows somewhere, it’s got to eventually get back to where it started via some path (hopefully not through the input stage of an unrelated component).
Now is the time to think about grounding schemes — and to figure out how the grounding characteristics of various devices will affect your system. For example, does some device have a DC-DC converter that introduces an AC difference voltage between the power supply side ground connection and the signal side connections?
You should be intimately involved in decisions about ground paths before commitments are made about how to wire-harness the system: Whether to chassis-ground a particular module, whether to add additional decoupling or filtering to the power supply connections, whether the adjacency of different kinds of devices appears problematic, and on which signal lines do grounds get lifted or connected (and on which end). I would say that now is not to soon to begin analyzing the components of the system for these issues.
Finally, a few other quick notes on matters various…
Frank, who seems to be getting involved in all sorts of aspects of this, tested my old 3M SCSI tape backup unit and my NEC CDROM drive on his Mac. Both seem to work, and he spent part of the day mounting the tape machine on an aluminum panel so we can start following sensible backup procedures instead of trusting that the fates will be kind to my precious data.
We’re currently trying to decide how to handle the network publishing issues related to this project. As you may know, we have a World Wide Web server and a Gopher server running on the Tadpole SPARCbook, as well as the ftp site at ucsd.edu. Much discussion is presently afoot concerning what should be on these and whether it can eventually supplant the infrequent mega-postings to the nomadness alias. We may even include these status reports, since many people want to track the project but grow weary of 2-3 month gaps between major listserv postings (and I grow weary of dealing with a hundred or more mailer daemons each time I do one).
Print media update: watch the San Diego Union sometime this week! Rumor has it that we may even get color photos…
Finally, if you are a UCSD student and you never followed up with any communication (like the questionnaire) after initially being added to this mailing list, you may be dropped soon. I keep the industry/friends part of the alias fairly well tuned, but there are some unfamiliar names among the 71 students currently receiving these reports. You can help me by letting me know if you’re NOT interested; we’ll do a note to everyone we haven’t heard from to give you one last chance before selecting your address and hitting command-X…
On that grim note, cheers from the lab! 😉
Microship Status 2/12/94
Forth Multitasker And Beeline Network
Hot news on the Microship control network front!
First, a highly efficient new multidrop protocol (BeeLine) is now operational! It uses the same New Micros modified RS-422 cabling setup, and has now been installed in the EEPROM of boards B and D. (We should have them all running in a few days, after a bit more testing.) The new protocol takes advantage of a hardware interrupt built into the 68HC11 and invoked (when enabled) by the high-order bit in any incoming character. If the rest of that character happens to match the board’s one-byte address (the same letters we have been using), then the UAR/T wakes up and a service routine is enabled along with the board’s RS485 transmitter via Port A, bit 3. All incoming data is subsequently placed into a ring buffer, and a new KEY routine works from the pointers to construct the data to be interpreted. Very slick. The only CPU paying the slightest bit of attention to multidrop traffic is thus the one currently selected — all others are totally devoted to their tasks and are only interrupted when the next node-switch character appears on the network.
Speaking of tasks, I’m even more excited to report that the round-robin multitasker is working as well! This is seriously cool stuff. At the moment, those two boards are each running three counting tasks in addition to their interpreters — which can freely display the variables of the others, compile new code, chat with the host, etc. In the past couple of days, the background tasks have all counted to 30 million or so…
This can all be attributed to well over a week of full time work by Bill Muench, one of the industry’s major FORTH gurus, as well as about 12 hours of phone time between us. (Too bad the phone company gets all the consulting fees… I suggested that he get a 900 number for future clients!)
Anyway, the tools are now looking very solid, with the exception of one incredibly obscure and confusing bug that keeps the multitasker from coexisting in the Hub with some of our initial test code. This has caused nightmares the past couple of nights, for it maketh no sense — when it crashes, we have to run WIPE in order to clear the EEPROM… even if the EEPROM protection register is set!
Once that is cleared up, we’ll have a powerful new development tool here. Each of the 16 New Micros 68HC11 boards on the network can run up to ten simultaneous tasks (including MAIN, the FORTH interpreter). None of the remotes will bothered by communication with the others. As these reports continue, we’ll be talking about some of the amazing things that can be done with multitasking controllers — but a few advantages are already clear:
- We can add new applications to systems already completed by other groups without any significant impact on the earlier work.
- Programs need not be complicated by long, convoluted “executive loops” that test dozens of conditions and act on the flags.
- All tasks other than MAIN are freed from network communication issues, allowing them to perform all I/O with variables and arrays.
- Conceptually, things are simplified since data collection and other continuous processes take place in the background, even when the system is under active development or engaged in compilation.
(By the way, we just received a shipment from New Micros containing three pairs of RS-232 and RS-485/422 interface cards, which will allow us to take nodes off the net for direct development with other Macs or PCs. As the rapidly nearing end of the quarter raises the stress level around here, this should take some of the pressure off by allowing up to four project teams to work on their FORTH boards simultaneously.)
GPS/nav Serial Communications
In our last issue, there was a sad little section entitled THE HEARTBREAK OF DATACOMM. Well, at least THAT problem is fixed…
As anyone who has done battle with RS-232 interfaces knows all too well, the durn stuff can be a royal pain. The trick in this case is that CTS has to be high at the ACIA pin. An easy way to do that is to connect CTS to DTR (pin 5-20 on DB-25 or 4-8 if DB-9), then program the appropriate control register such that the DTR output is held low. I think there should be an on-board jumper on all serial boards for this sort of thing, allowing people to use a simple 3-wire RS-232 interface without extensive research through databooks and published lists of RS-232 port pin assignments.
Once we fixed that, the Motorola Traxar GPS began happily transmitting data to the Hub via a simple communication loop on the navigation processor. It is now up to Henry Xia to write some code to parse NMEA sentences and deliver items of interest upon command.
Ampro System Status
The ship management computer is getting closer to life by the day. Sharp shipped a model LQ6NC01 active matrix color LCD (6″ diagonal). This is a lovely little unit, to which can be screwed the backlight inverter and Ampro interface board. This then connects to the VGA controller for use as a system monitor. With the toggling of a control bit, the display instantly becomes a video monitor that directly accepts standard NTSC (eventually via the video crossbar system). I went to the Underwater Intervention Conference last week and learned a lot about video at sea, so this is definitely going to be useful.
We have not yet fired it up, however, since we’re still trying to get the basic system going. This morning Frank and I tried again to get an IDE hard drive working and were unable to get the computer to recognize the existence of a Seagate 40 megger patiently spinning away on the bench. The next step will be to borrow the SCSI drive and controller from BEHEMOTH in order to get a development environment going — this system will eventually become the graphic user interface to the control network.
PARTS: Parts continue to trickle in from everybody except Digi-Key, which is turning out to be the slowest of the “Fast turnaround! No charge for rush order!” suppliers. Halted in Silicon Valley shipped a mass of IDC cable and headers, the rest of the zeners needed by the SeXBAR team, perfboard, and a couple of cool military sealed boxes for on-deck control/display use.
KAYAK ARRIVAL: Bobbi Smith arrived here Friday in a rental car after a three day marathon drive from Victoria, BC with her Doberman, Sprint. Atop the car, neatly wrapped and expertly tied, were the new Current Designs custom Libra double kayaks. These have now been deposited in the boat shop at Scripps and are ready to be unpacked, placed on cradles, and subjected to extensive modifications. Suddenly the Microship seems much more real… two of the three hulls exist!
MARINE ARCHITECTURE: Robb Walker just emailed me an IGES file, which imported neatly into AutoCAD. The center hull is taking shape as well, and is now awaiting input from Scott Poorman’s weight study to take on specific dimensions. Meanwhile, TJ and Jeff are focusing their efforts on a test structure in Mentat, the finite-element analysis tool that will be used to refine the internal frame structure. We’re all surfing the knee of the learning curve…
Microship Status 2/15/94
by Steven K. Roberts
Aaagggh! Keeping up with documentation is impossible — not only this series of project status reports, but also the BIG BOOK of specifications. I am making lab notes, but somehow they all have to make it to clean documents before I forget their context…
(The reason for that outburst is actually good news — so much progress is happening that I agonize over the difficulty of keeping track of it. That’s far better than keeping careful track of NO progress, however…)
Control Network Flickering To Life
Soon this topic will move into the background where it belongs, since it is, after all, just the infrastructure. Paying too much attention to it is akin to buying a computer as a book-writing tool and then spending the next two years fiddling with the computer. But we gotta get it right, and that’s happening.
The “obscure and confusing bug” I mentioned last time is now just history, though it didn’t fall without a fight. Two things were happening — fast high-level coded datacomm was trying to coexist with the multitasker, swapping out on every occurrence of ?TERMINAL or KEY. The overrun conditions from the network appeared as missing characters, which became spacier the more tasks were running. The high weirdness occurred when we hit reset to get out of that and found the board forever inaccessible… requiring the WIPE utility (we thought) to erase the EEPROM. As it turned out, we just needed an extra instruction in the startup routine to point at the right user area… something unlikely when leftover task-switching pointers are still there after a crash. It’s fixed, and the lesson is that RAM doesn’t necessarily forget completely upon a power cycle. New autostart code immediately initializes all pointers.
The original problem that smoked that out is still there, however, and that is the difficulty of dealing with high-speed serial datacomm via software while a multitasker is active. There are a couple of kluges that could fix it (like disabling tasking during comm strings), but we’re implementing the correct solution: another interrupt service routine for the network interface, complete with ring buffer. Bill Muench is writing the serious code, and we should be integrating it in a day or so.
All that aside, it’s really amazing. We’ve been installing the new BeeLine comm protocol in various boards, hanging them on the net, then downloading the tasker and a file of test code. We can select any board by simply clicking a button on the MicroPhone screen on the Mac (or via Hub code, of course).
I’m also adding a cluster of three LEDs to each node, and the two completed so far are already proving to be useful:
- YELLOW (Net): lit whenever the node is enabled onto the multidrop bus via PA3 (port A bit 3), providing a visual indication of network activity and node scanning. The catch here is that the 75176 drivers are power-hogging NMOS (35mA!) and soak all the power the poor HC11 pin can muster… driving the LED without taking the board offline took not only the traditional low-side NPN switch but also an emitter follower AND a pullup! (Anybody know of a CMOS pin-compatible equivalent?)
- GREEN (Health): controlled by PA4, and owned by a dedicated task in each node that combines health and watchdog (COP) functions. A flicker about once a second will indicate a working board, and we might arrange things so that the frequency reflects tasker loading. This same task also provides the values (board ID and health code) returned to an ALIVE? query from the Hub.
- RED (Prog): controlled by PA5 and used by each application for debugging, status indication, error conditions, etc. Examples include a brief flash on each receipt of a GPS string in the Nav processor, security mode status, all-buses-busy on a crossbar, autopilot corrections, etc.
Now that things are waking up and feeling stable, we’re seeing the project teams making additional progress. Today Henry (GPS), Carl (Ultrasonic), and Chris (Hub) worked together for about 3 hours on the NMEA nav sentence array and parser, making great progress in FORTH understanding as well as problem clarification. Michael (Hub) whipped up a 20-key keypad the other day for the helm controller, Isaac (AuXBAR) is working on the initial Hub-response code, and as I write this at 11 PM, Jeff (SeXBAR) is in there wiring the crossbar board. I started playing with an LM335 temperature sensor and the A/D system last night, and Prof Guest helped today with op amp level shifter design. I designed a “tri-state detector” that will let the Hub easily determine whether the net is responding appropriately to node-select commands. And I mounted a pair of the New Micros level converter boards on the Hub chassis along with a big honkin’ 4PDT switch, allowing the entire network to be toggled between the Hub serial port and an external RS-232 device like a PC.
The Hubfolk and I have been defining a suite of standard commands that will have to be handled by all nodes on the net. Much of it has to do with robustness and error-handling — we’re cooking up a protocol that should allow failures at just about any system level to be detected and, hopefully, handled automatically. (We will be able to issue a master reset to the entire network, cold-start any truly ailing node, then restart all taskers and applications in a single utility.) We’re also defining words like ALIVE?, SHOW, and NEWS?, which serve respectively to yield health and ID data, a snapshot of current activity, or routine status and internode mail. In addition to all this, of course, the Hub will transparently pass application-specific traffic to and from the various subsystems.
Speaking of the ECE-190B project class, HOT NEWS in case you missed it earlier today! Clark Guest notified me that the Electrical and Control Engineering Dept here at UCSD has approved a Spring quarter session of the senior project class — meaning that in March we’ll be able to start another whole team on control system design. There’s still plenty to do — packet radio links, battery management, power distribution, security, bay pressure control, bilge control, more nav processing, autopilot, graphic front-end tools, environmental data collection, and more. Now that the network is reasonably stable and there’s an emerging FORTH-literate culture producing working systems, a good design context is established and this is a GREAT time to jump in.
So if you’re an advanced (senior, beyond, or experienced) engineering student here and want to get involved in a somewhat more formal context than the scarce 199 technical electives, this is the time to act… please contact me ASAP. Also, since these postings are to a relatively small mailing list of 100 or so people, please forward as necessary to any creative people who might be interested.
Rembember the CDT list? If you’re around campus and want to help out, but aren’t ready to take on a full-scale project, here’s how. I’m maintaining a “clearly defined task” list as a stack of 3×5 cards in a box in the lab (a sort of old-fashioned database method, for those of you who’ve never seen such a thing). Here’s a quick one-liner summary of what’s in there at the moment — if anything sounds amusing, please let me know:
- Build rack for wire spools
- Contact database updates
- Photo scanning for the WWW server
- Research equipment bay connector standards
- Clone BEHEMOTH’s LED matrix scanner
- Self-scan analog mux and digital panel meter
- Choose pressure sensors
- Pack and ship a few things
- Find and repair leak in kayak flotation bag
- Resistor and Capacitor inventory organization
- IC inventory organization
- Woodworking for solar still project
- Build kayak support cradles
Progress on the Ampro PC! Frank and Dan have repackaged the hardware over the past couple of days, now that we have gotten the system working with a SCSI hard drive borrowed from the bike. The IDE controller must not be well — we tried it with three drives, but SCSI came up easily and also runs the 3.5″ floppy that wouldn’t work earlier. I’m looking forward to packaging the new Sharp color display and firing it up…
Silicon Valley Bus Company shipped the Keystone, which is a magical little box designed by Jay Hamlin. Plugged into a Mac ADB port, it allows a standard PC keyboard and mouse to run the Mac. Ain’t technology wonderful? This is of great value here, since it will allow one waterproof suite of console devices to run all on-board systems.
The Digi-Key shipment arrived, containing the horrendously expensive SeXBAR connectors, 60 nifty little LEDs with internal resistors, 50 2N3904s, the temperature sensors, and a universal PLCC removal tool.
Luke is continuing to capture project video, and we’re hoping to head down to Scripps this weekend to unwrap the new kayaks for posterity (unless that happens during an upcoming meeting with Drew from Nelson/Marek on Thursday).
Microship Status 2/25/94
I added a few long-awaited features to the Hub processor. The first is the High-impedance detector, which allows the CPU to detect whether a selected node has in fact responded to a BeeLine event by enabling its RS485 driver onto the network. (It’s just a 74HC00 gate package with a couple of pullups, feeding both an LED driver and port E, bit 2.) From a hacking perspective, this is nice because it provides instant evidence of a link between Hub and Node — both participants in a traffic event have a yellow LED on. From a reliability perspective, it will let us detect a failed or non-responsive node and react appropriately.
That appropriate reaction involves the second Hub hack — Port A bit 3 is now a master reset to the entire network. I had to do this with a MOSFET to prevent an odd ground-loop problem, but otherwise it’s great — Hub code can stop all processes, then selectively restart the taskers and launch applications or even cold-start where required.
Incidentally, I noticed when testing this that there is an error in all editions of the Motorola 68HC11 databook — the I/O chapter still doesn’t document the bits in PACTL that enable the corresponding bits in Port A to be outputs. The unclean-FORTH master reset pulse is generated by:
: NETRESET B026 C@ 08 OR B026 C! B000 C@ DUP 08 OR B000 C! B000 C! ;
(If you’re working on the project, please use constants! This is just the test version….)
The Hub now has the standard green and red LEDs for tasker/health status and program-generated flags and alerts — if nothing else, they’ll be useful during development.
By the way, I just got specs on the Linear Technology LTC485, which will hopefully serve as a drop-in replacement for the power-hog 75176 RS-422/485 drivers…
The ECE-190B class is moving ahead at varying rates, with deadline only two weeks away. The AXBAR team (they didn’t like “AuXBAR”) discovered that output channels C and F (hex) on both boards were inoperative; I compared the schematic to the board and found a netlist error that caused the op amp wiring to be scrambled between two devices in one package (pins 2 and 13 swapped). Dremel and #30 kynar fixed it. Input channels C also fail, but I haven’t stared at them yet. Isaac made the 8 bus jumpers to tie the two 16-by-16 boards together, and Jason tested all the code… the audio crossbar is almost done.
The SeXBAR team has finished the wiring of their perfboard, just in time for the beautiful new sponsored Vero Speedwire board of perfect dimensions to arrive (hey, you guys want to re-do it? ). Testing is about to commence… and software should go smoothly since it is very much like AXBAR.
The video crossbar hardware is underway — Delon is installing four 88V32 chips directly onto the prototyping area of the New Micros board. A single 96-pin Eurocard connector will handle all video I/O. As I write this, he’s in the lab creating the first version of his FORTH code… occasional mutterings and exclamations echoing from the concrete reveal the complex and wondrous joys of programming.
I just fired up the Sharp active-matrix color LCD on the Ampro 286 system. It’s beautiful, but at the moment the selected VGA mode is cramming an entire full-screen display onto that 6″ space… we need to learn more about how to control it. The color is rich and amazing, however, and we’ll test it with video soon.
We will probably be adding an additional node to the network — a performance analysis system that monitors load-cell stresses at the mast base and outrigger supports, air pressures in the vicinity of the sails, and other dynamic criteria. In addition to yielding an interesting database, this will provide a critical “redline” function that will let us know when we’re pushing the vessel too hard.
One of the engineering projects for next quarter may be the autopilot system — a group is showing strong interest in taking a fuzzy logic approach, implemented in FORTH. The primitives should be quite publishable, and the results should be interesting…
We had a meeting with Drew of Nelson/Marek a few nights ago, convening at the Seaweed Canyon shop (site of a “field trip” this coming Tuesday at 1:00 for any directly involved individuals who want to see the kayaks). The intent was to stare at the outriggers, contemplate their buoyancy, think about attachment methods, puzzle over deck fixtures and streamlining, and otherwise ponder what to do next with these beautiful Libras. My first CDT is to give him a data point on volume — we know that the whole boats are 184.4 gallons each, but we need to know how much flotation can be expected BEFORE they are fully submerged. To that end, we just ordered the hardware for the kayak work stands, and will separate one hull/deck pair and fill a hull to the seam with packing peanuts… then measure the amount using a box of known dimensions. We could use water, but the weight would likely break the unsupported hull…
Dan Yang built a lovely wire spool rack for the lab, another step in clutter minimization.
Jeremy Heath is making good progress on the custom antenna mounting clamp for the roof — all it needs now is a coat of stealth paint and installation.
Luke Abbott and I are continuing to collect video of various events and ongoing work, looking at producing the first of our project documentaries as soon as we work out the complex details of production facilities and duplication.
A netfriend named Tara from New York came to visit last week and we capped her winter respite with a hot air balloon trip. Although this has nothing to do directly with the ship, I feel compelled to report it here because it was one of my most exhilarating breaks from lab frenzy in a long while, and well worth it!
Technical Report Series
I have begun a series of NRL Tech Reports, intended to replace the occasional Nomadness Report journal and the not-yet-off-the-ground BEHEMOTH TECHNICAL MANUAL. These status postings will be available in hardcopy, with much more cogent reports on single systems published as standalone documents replete with schematics, photos, and FORTH listings. Where appropriate, these will carry acknowledgements or shared bylines with those who have contributed significantly to the work.
The publications will be divided into series as follows, with the covers RETMA color-coded for quick recognition:
100 Brown General Nomadness Topics
200 Red BEHEMOTH Technical Papers
300 Orange Winnebiko/BEHEMOTH adventures
400 Yellow Microship Technical Papers
500 Green Microship Status Notes (Monthly)
600 Blue Standalone Detailed Technical Reports
700 Violet Microship Adventure Tales
800 Gray Miscellaneous Topics
I’m currently working on the logistics of publication, but the first ones out the door will probably be the monthly collections of these progress reports, starting with July 93. I’ll let you know when they become available…
Microship Status 2/28/94
End of February already! We’re only a week or so away from the end of the Winter Quarter, and things are intense… this quick update will wrap up the month and also the recent backbreaking weekend marathon of network code refinement with Bill Muench.
CONTROL NETWORK WRAPUP
Yes, it works. The multitasker has been refined with key code segments reduced to low-level, and it is almost three times faster under some conditions. Even more important, the Hub can be vigorously multitasking without affecting 9600-baud communications over the network — as you may recall, the tasker was preventing timely service of the old software-driven NETLOOP program. Well, now we have a second ring buffer and an interrupt service routine that handles the network. Since this is the Hub’s major role in life, this is a major step forward, but it came at a cost of about 12 hours in The Chair and my back is still paying for it…
All this new code is compatible with the nodes, and at our leisure we’ll drop it into their EEPROMs. At the moment, taking the network offline is dangerous since deadline approacheth for the 10 students remaining in the project class. When I can, I’ll upgrade the hub to 64K of RAM. The net effect of all this, so to speak, is a very stable and FAST network of FORTH processors, seemingly expandable ad infinitum. The New Micros boards are solid, the multidrop network is noise-free, and Bill’s code is brisk and efficient. This infrastructure will be with us for quite a while, so the next step is catching up with documentation so the next student team will have a stable spec to work with.
THE VIDEO LCD
I mentioned in the previous report that we have fired up the Sharp LCD on the Ampro system… sometime over the weekend, I cabled my Sony TR81 camcorder to the NTSC input, pulled the requisite control bit low, and VOILA! The most amazing little 6″ color monitor I’ve ever seen! This is not at all what you’d expect from an LCD — it looks like a small, high-quality TV set. With Tim Chen snapping photos, we did the usual video play (eyeball close-ups, feedback, and the like), and now it’s time to integrate it with the video crossbar system that Delon Levi has almost completed.
Progress! I’m pushing to get document NRL-401 out the door — I’ve just agreed to exhibit BEHEMOTH at a computer show in Pomona in mid-March, and I want to have something to sell that’s technologically more current than Computing Across America (in which I set out with a Radio Shack Model 100 and a 300-baud connection to CompuServe, then upgraded to an HP laptop and a blazing 1200-baud modem). A mercifully short update thus ends a mercifully short month…