At a Glance

My first embedded product.  (The first of many.)

I provided the complete hardware and software design for two very different iterations of this avionics product in 1984-5.  Among the things I provided were:  schematic-diagrams for 5 circuit boards, 21.5K lines of firmware written in Zilog Z-80 assembly-language, 11.7K lines of MS-DOS support software written in Pascal, some (unknown quantity) pages of documentation for software-certification and other purposes.

Background

The Heads Up Checklist is the product which Heads Up Technologies, Inc., was formed to manufacture and market. My involvement with the project pre-dates the existence of the company. While in graduate school, in 1984, I was approached to design the hardware and software for this product as a spare-time project. The goal was to exhibit prototypes at an aviation trade show, the NBAA, in late 1985, and to form a company if potential customers showed interest.

The idea behind the Heads Up Checklist is that it provides an audio checklist for pilots. In other words, instead of referring to the printed checklists which must be provided in every aircraft, the pilot instead is able to hear his checklist spoken aloud. The checklists used by the pilots, though in theory standardized, are in practice highly customized. Each pilot who uses a checklist tends to create his own customized version of the checklist.

The initial prototypes were the first electronics design I had ever executed except as a hobby.  They were based on a 2 MHz Z-80 micro-controller with 16K-48K bytes of EPROM and 2K bytes of RAM.  (As a hobby, I had earlier created a Z-80 based CP/M computer computational back-end that used a Radio Shack TRS-80 computer as a front-end supplying the keyboard, monitor, and disk drives.  The checklist prototype design was based loosely on this hobby experience.)  A phoneme-based speech chip was used, allowing each spoken word to be represented by only a couple of dozen bytes of memory, though at a loss of understandability and aesthetic quality in the playback that was very great. The program was completely written in Z-80 assembly language.

A very important difficulty that needed to be overcome in creating the prototypes was that there was no easy way to create binary phoneme sequences representing hundreds of individual words needed for playback, since the phoneme codes each represented only small portions of words. I therefore wrote an IBM PC-XT program, called SDS, that could be used both to interactively edit/playback phoneme sequences, but also to perform rudimentary text-to-speech conversion. The latter feature allowed a crude but usable sequence of phonemes to be created for any given word, so that the phoneme sequences for words needed only manual cleanup by the person editing them, rather then needing to be completed from scratch. The text-to-speech algorithms were based on a heuristic rule table, in which various patterns of alphabetical characters were translated to associated phoneme-code sequences. Thus, a way was needed also to edit the heuristic rule table. Of course, I also had to design a phoneme-based plug-in card for the PC-XT to allow the person editing the phoneme sequences to play them back audibly.

By the way, when I say "IBM PC-XT", I am referring to the original 4.77 MHz Intel 8088 IBM PC.

This SDS phoneme-editor program was written in Turbo Pascal. Though long-obsolete, the program nevertheless has some interesting characteristics. You can view the SDS manual, in Microsoft Word format, by clicking here.  (Of course, the manual was not written in MS-Word, which did not exist, but I've converted it to MS-Word as an exercise in technological archaeology.)  Here are screen-shots of the phoneme-editing spreadsheet for the word "hello" and of the rule-table editor:

At NBAA '85, customers did indeed exhibit interest in the product. As a result, the company (then called "Heads Up Checklist, Inc.") was formed, and I became the first (and at that time, only) full-time employee. However, the consensus of opinion seemed to be that the audio quality was very poor due to the phoneme basis, and that the product would have to be drastically re-designed before it could be marketed. This was a drastic limitation, since cost and memory were severely constrained. Fortunately, I located a California company called Electronic Speech Systems which marketed an audio-compression algorithm that could be exploited to allow audio-playback of most words with only 300-500 bytes of memory per word. The audio quality was still extremely poor by modern standards, but was better and more natural than the phoneme system, and was adequate for 1985.

Therefore, I re-designed the checklist hardware with no speech chip and 160K of EPROM, and I re-coded the firmware to include Electronic Speech Systems' algorithms. The company's flagship product was thus released in early 1986. While the SDS program described above was now obsolete (Electronic Speech Systems provided the development system used to created the compressed audio files needed), I was still forced to provided various support-software packages (i.e., MS-DOS programs for the IBM PC-XT computers in our offices) in order to make manufacturing practical. Since each checklist unit is shipped with a different pilot-customized checklist in it than every other checklist unit, it's necessary to maintain a large databases of these checklist. The checklists are maintained in textual form, and when processed are converted to audio data. It is thus necessary also to maintain a large database of compressed audio data. I wrote the programs used to maintain these databases and to process the textual checklists to audio binary form suitable for inclusion within the checklist units. These were MS-DOS command-line programs, written in Turbo Pascal.

I also wrote some rather significant support software to aid in the process of compressing the audio clips.  The compression process, as envisaged by Electronic Speech Systems, was almost entirely a manual one.  The person guiding the compression process was supposed to view a visual representation of the wave-form of the clip, and through training was also supposed to be able to recognize the various significant facts about the clips.  Firstly, he had to know which areas of the wave-form represented "voiced" rather than "unvoiced" sounds.  Secondly, for the "voiced" areas -- which were semi-periodic -- he had to place markers at the beginning of each periodic interval.  Once all these markings were added, software provided by Electronic Speech Systems could produce the binary compressed data; but the quality was very highly dependent on the quality of the marking.  As you might imagine, this was a labor-intensive process, which might require 10 minutes per word of manual labor.  (In fact, Electronic Speech System's business model really relied on having them compress the audio clips, rather than having their customers do so, at a non-trivial cost per word.)  To get around this, I provided my own software that was cabable of analyzing the raw audio data and providing substantially better markings.  (It was necessary to hack the file format used for the markings to do so.)  This reduced the labor substantially, as well as improving the compression quality.

Another significant side-effort went into creating an "emulator" that made it easier to review the checklists.  Programming EPROMs and placing them into a checklist unit was a somewhat time-consuming process in those days, and the end result was all-too-often to find that the compressed audio didn't sound good and thus needed to be reworked.  I therefore built a box which contained portions of a Heads Up Checklist, as well as additional circuitry, that connected to an IBM PC parallel port.  In essence, this emulator replaced the Heads Up Checklist EPROM with RAM, which could be uploaded from the IBM PC.  Of course, I also provided the software used for this uploading.  The net result was that checklists could be reviewed after quickly uploading them to the emulator box, rather than inconveniently creating EPROMs.  This enhancement of checklist QC had the result of greatly speeding up the production and programming of the units.

Finally, as an aviation product, the firmware must obey some constraints that don't apply to firmware in commercial products. The Federal Aviation Administration requires certification of aviation firmware according to principles set forth in RTCA document DO-178. In essence, DO-178 is intended to enforce a certain flow of design activities, the main practical effect of which is to require the production of various pieces of documents, along with a paper trail interconnecting these documents with the design activities themselves, and among each other. The documents cover not merely the firmware, but also a wide range of only-marginally-related issues such as backups of the development-computer system, markings on the units, markings on the EPROMs within the units, version control, baselining, code-walkthroughs, testing, and so forth. Thus, it was necessary for me not only to produce the rather-lengthy DO-178 documents for the Heads Up Checklist product, but also to basically create the entire general software-development system which these documents documented.

This version of the checklist unit was marketed through 1987, when it was replaced by the so-called "Gold" checklist unit.