Overview

My current portfolio consists of projects completed for businesses that I was employed at. They typically had needs and I filled those needs with what tools were available, or we determined what tools were needed and after acquiring them, stretched them to their limits. In any case, here they are beginning with most recent. Work in progress is not shown.

Hazardous Gas Controller – III

This was a new product for a new company, and there were only two of us to do the software, oversee the hardware, and get it all put together. And a year to do it in. A challenge and an opportunity. This involved acquiring workstations, desks, and a file server just to get started. Then we talked with marketing and sales to define the scope of the project.

We ended up with a novel design that had us contract hardware design to create an interface board that could be configured and end up running standalone should a software or hardware problem corrupt the computer, my name is on a patent application for this product. The computer was an off the shelf low cost Single Board Computer that ran from an EEPROM and interfaced via PC104. We used QNX due to its realtime extensions, reliability and licensing cost. We shared the design tasks and used structured methods to lay out the functions and data needed then began to implement the software. This device also supported RS-485 networked communications. During all of this we also did project management and source code control, as well as bug tracking.

My additional duties were to oversee our hardware contractor, provide wiring diagrams and BOMs. As everything came together, there were last minute changes, of course, and we ended up having to do a second revision of the hardware, which also meant updating the drivers. In the end it all came together and was running at the trade show in Austin, TX. We also applied for UL listing, and got it. There was some time spent by yours truly at UL as we had to apply some shielding around a very long video cable to prevent it from accepting RF interference.

After these units shipped, we had gotten a report of some IO problems. Turned out the devices initially specified for clamp diodes needed to be changed. I was fortunate enough to be the one to go to the overseas customer site, and replace the surface mount devices with soldering iron in tow.

Hazardous Gas Controller – II

This was a second generation custom controller for this company. We had three people doing software for this project and I double duty as hardware overseer. This was a custom controller that had an I/O board specific for this application and was computer controlled to show status. The computer could also respond to data over two RS-485 networks; one connected as multi-drop to communicate to a central monitoring computer, the other to talk to a handheld computer that provided cycling instructions. Both computers were running OS-9. This was a pretty big jump by the semiconductor industry as they typically did not like to accept computer controlled devices in their gas handling equipment.

Key to this project’s success was the use of structured methods and source code control. While there were three people on the team, we did have people come in and out of the development over the course of the project. The definitions created through these methods meant modules, or functions, could easily be handed out for coding without knowing anything but that modules definition. Source code control kept the software from getting out of hand, especially as the debugging stage was entered and code being checked in and out was happening fairly fast.

RS-485 networking and installation was overseen by me to train our technicians and provide support to our customers. There can be quite a few hurdles when installation isn’t followed to the letter, and there were several trips to customer sites to find and fix just such problems. Overall this was an exciting project and proved the importance of upfront design and attention to detail for managing a team.

Hazardous Gas Controller – I Interface

My first project in this industry was to program a communications board that would allow the existing hardware to transmit information to a central computer, and accept a few commands. The original hardware had no processor, so the new board was the only intelligence. The program was written in assembly for a Z-80 computer and peripherals. This was my introduction to structured methods, and it was enlightening. I was sold on it immediately.

As the product aged, one of the chips in the communications board reached end of life, so the board needed to be redesigned with a replacement. This was not a problem for software as only a few pointers should need to be updated. Alas, the new board would not entirely work upon arrival. Turned out the hardware designer misunderstood the data sheet and left some address lines unconnected thinking they were not needed. I was able to identify this problem between the schematics and datasheets. adding a few wires proved the point and the board was revised and worked fine.

This product was used for quite a while and added into a large number of existing devices that were in the field before it’s implementation. Sometimes the simple stuff makes a big difference. It should be noted that development was done using vi text editor on a HP-UX computer through an ASCII terminal. A cross assembler and emulator from HP was available.

Network Monitoring System

One-way Satellite data communications in C-band using a 2′ diameter dish was a big deal in the 1980s. Spread spectrum had just been released for private sector use and the company I worked for was making it happen. The data center had incoming data from telephone lines and high speed dedicated connections, as well as large aperture satellite feeds. Data coming in went to computer interfaces, packetized, sent to a redundant chipper to spread the signal, modulated, amplified and transmitted to the satellite. The center also received its own transmissions, and compared it to sent data to check for errors.

This entire path was littered with alarm points so that each  portion could report problems. The control center needed a centralized way to visually and audibly know that a problem existed. The hardware choices were not mine to make, so it made for an interesting project. The display was a large Color CRT that had some limited graphics macro capability. The hardware was an ADAC computer and interface hardware that ran from an 8″ floppy drive.

The challenges were many; the language was basic, the program memory was not sufficient to hod the monitoring program and the graphics, the hard drive had to log and time stamp information, and the operating system accessed the floppy each minute due to how it handled the clock. The inputs were supposed to be edge triggered, but they could lose events, so scanning still had to be done on hundreds of points.

This project included wiring the remote points, interfacing the various hardware to isolated inputs, making sure it was all fail-safe even if the points provided were not initially designed that way. The solution included chaining two programs; the first  would program the graphic macros to the display, and the second program was the monitoring program. This device ended up being invaluable to the daily operation of the network by alerting 24/7 personnel to potential problems before they became big problems.

Network Logging System

The data center described above had a printer attached to each link, which could have up to 16 data streams applied to it. Any anomalies, power restart, or significant event would have a one line time stamped status sent to the printer. This meant technicians had to check paper and ink on many printers each day and put the printouts in various binders for future reference should a problem be reported and require searching for the log entry related to it.

We had just gotten a PC and SCO Xenix in the data center for use at one of the workstations. A multi serial interface board from Digi was attached to it, and I proceeded to connect each printer to the computer. Each serial stream was sent to a specific log file, each night the computer would close the day’s files and open new ones. Saving time and paper.

Searching for specific events was easy using awk and regular expressions. This saved a lot of time and was much faster to find information among all the lines of events. The cost to implement this was higher than it would have been today, but was still very cost effective.