Richard Heurtley's Resume
I am a talented, experienced, and prolific computer programmer. I mostly use the C language and have experience in the following areas:
Q: vi or Emacs?
Q: Slashdot ID?
Q: Linux distribution?
For the last 18 years I've been an independent consulting computer systems engineer with clients in the Vermont area.
10/10 to 5/16: Computer Programmer
Housing Vermont is a non-profit developer of affordable housing. Housing Vermont's Energy Project Manager approached me about his idea for an ultra-low-cost data monitoring system to find out how well the equipment he's been installing works. We call the result Hard'ack and intend to make it open source.
01/09 to date: Computer Programmer
NOTCH is a Federally Qualified Health Center with clinics in five rural Vermont towns. Back when NOTCH was just the Richford Health Center I was the volunteer IT guy until the operation got big enough to warrant hiring someone. Later NOTCH approved a modest budget for some custom applications including a web-based vacation scheduling program and some apps to help manage a prescription drug subsidy program.
11/04 to 01/09: Computer Programmer
Kaycan is a manufacturer of aluminum and vinyl siding. I developed a Linux-based controller for a vinyl resin blending system.
09/99 to 01/03: Technical Director
EPS is a service bureau for the subsidized housing industry. I set up their original data center and wrote a large shell system around their core commercial program. Later I was hired to advise on updating their data center with modern equipment. I recommended centralizing and virtualizing their servers with a blade array, VMware, and some SAN storage arrays.
07/98 to 03/99: Senior Software Designer
Hyperchip was a start-up developing high-speed network switching technology. I wrote several switch architecture software simulations and an efficient high speed NT device driver for an FPGA PCI card.
10/94 to 07/98: Computer Programmer
Quinton made cardiology equipment. I was originally hired to help rewrite their Q-Cath application using Vermont Views. Later I helped port the DOS application to Windows NT.
01/91 to 06/93: Senior Software Engineer
Telerate distributed real-time bond, foreign exchange, and commodity information before the advent of common Internet access. The New Orleans office wrote and maintained the real-time DOS program that displayed the information. The group created and used an innovative language that was interpreted, stack based, threaded, and object oriented. I ported the interpreter from real to protected mode, added a source code debugger, wrote several printer drivers and productivity tools, and developed a Huffman based scheme to compress the information feed.
10/88 to 12/90: Senior Software Engineer
Originally VCS's main product was a data entry forms library called Vermont Views. I wrote extensions to let the library render in DOS graphics mode, use expanded memory, and process mouse events. I also created a DOS testing tool that records and plays back keystrokes and compares the resulting screen images. All VCS programmers spent considerable time providing technical support to customers.
04/86 to 10/88: Senior Software Engineer
Anderson-Jacobson manufactured a line of modems. I designed an add-on Z80 processor board for an existing 2400bps modem and implemented the MNP error control protocol. I then designed the controller section for a 9600bps modem using an 80186 processor and wrote the small real-time kernel and data flow logic necessary to support the modem control functions.
10/84 to 04/86: Software Engineer
ITT Information Systems manufactured a line of IBM compatible personal computers. I was in a group that developed a voice interface board and associated software.
In 1984 I emerged from Rensselaer Polytechnic Institute with a Bachelor of Science degree in Computer and Systems Engineering.
Low cost data acquisitionHousing Vermont wanted to be able to monitor the heating and electric systems in some of its properties. They specified three criteria: low cost, cheap, and inexpensive. I wrote a set of programs that run on any Linux or Windows computer. We've used the following Linux systems as site controllers:
The site controller programs are:
The gather program can process the acquired data in various ways before writing it to the text file. The most useful processing is integration over time. This allows the gather program to calculate:
The remote server is a surplus workstation running CentOS. It runs the following programs:
An example of the nexus chart specification form is here:
The resulting chart is here:
A snapshot of the real-time data display rendered by the controller is here. The rows can be arranged over multiple pages:
A summary of my latest work with the Hard'ack system. "Some Thoughts on Drone Borne Gas Sensors":
Fun with temperature charts
Rendering annual temperature charts for different locations using various curve fitting techniques:
Rendering charts of 30 year global satellite temperature data:
GPL washing machine
My washing machine has a 12-volt DC motor that was originally controlled by some clever plastic gears and a DPDT relay. I had to replace the relay a few times and when the gears started to wear out I decided to replace them with a PLC. I wrote a C language program to verify the ladder logic program before loading it to the PLC:
Microwave line-of-sight coverage tool
The State of Vermont floated a bond issue to improve the State's telecommunications infrastructure. One of my friends owns two large centrally located hills in the Town of Richford and gathered together a group of knowledgeable people to explore the possibility of erecting cellular or WiMAX antenna towers. I wrote a program to determine coverage areas for antennas of varying heights at different locations. An example configuration file is:
The results are available at:
The program has the following interesting aspects:
A neighbor, one of Kaytec's vice-presidents, hired me to automate a vinyl compound blender for the company, a producer of vinyl siding and other extruded vinyl products. The result is 67K lines of code, only about 12% of which make up the state machines that actually control the blender. The system has the following properties:
The blender has been running for several years without program issues. I used the LaTeX system to write the 153-page user's manual.
The user's manual chapter that describes the blender program is:
XTroll: A filtering web proxy for the reason.com Hit & Run blog
One of my news sources is the libertarian-oriented web site reason.com. Anyone can submit comments to their lively Hit & Run blog. I personally find some prolific commentators repetitious and irrelevant. The blogging system does not have a filtering function so I wrote one and released it under the GPL. As far as I know I'm the only one who uses it, but I use it all the time. It's available at:
Workflow: A system for subsidized contract administration
EPS, Inc. of Williston, Vermont has contracts with several U.S. States to administer subsidized housing contracts, mostly HUD Section 8 contracts. The system I wrote for them is the biggest I've done single-handedly at nearly 100K lines of code. It consisted of several batch programs and a large cgi-bin web program for the interactive bits. The initial system comprised a Samba file server, an Apache web server, a PostgreSQL database server, and a fax server. All the servers ran Linux.
The data-processing cycle worked roughly like this:
The file formats used by HUD are complex and inconsistent. Much of the processing was just trying to determine the property and/or contract to which a piece of data referred.
The e-mail programs with client-side implementations of the SMTP and IMAP protocols are available at:
Hypercube network router simulator
I had a brief stint at Hyperchip, a Montreal startup in the backbone Internet router business. There wasn't much for the software guys to do while the hardware guys were still developing so I turned the pages of my notebook back to a lecture the company's president gave on hypercube network topologies and wrote a simulator. First I designed a corner node store-and-forward processor that could conceivably be implemented in hardware and then implemented it in software. I used a 10 dimensional hypercube (1024 corners) with 16 ports per corner node. Ten ports talked to each node's 10 neighbors, one port was the "hyperspace" link to the opposite hypercube corner, and the remaining ports were for attached devices. The processor could spread broadcast messages efficiently, respond to supervisory messages like "ping", and would forward regular traffic to the node closest to the packet's destination.
The GUI was 32x32 grid of 16 tiny squares arranged in a diagonal, each representing a port. Yellow lines were drawn between squares as messages passed between ports. The user could inject a message and watch it be propagated through the hypercube. Unfortunately if one injected more than a few broadcast ping packets the network got gridlocked. I never did solve that problem.
The Quinton Q-Cath hemodynamic monitoring system
The Q-Cath system is the largest I've worked on at about 130K lines. I was responsible for about half of it. The project started out as a rewrite of an existing program for extended DOS mode and continued when the program was ported to Windows NT. I wrote my first Windows device driver to support the system's proprietary ISA card.
The most interesting part of the project was rendering real-time waveforms on the PC's screen. The hardware platform was nothing special for the mid-1990s and there was no particular video hardware support. To move waveforms, I calculated just the pixels that changed between columns and effected the changes in a tight assembly language function called by a timer interrupt.
The heart of the Q-Cath system was a proprietary single board computer with a touchscreen interface. This connected the input signal conditioner, PC, non-PC waveform display, and chart recorder. The firmware needed some updates for new features so I had the opportunity to dust off and exercise my 16 bit programming skills and EPROM burner.
Digital cineloop machine
A Q-Cath system is half of a hospital's catheterization lab equipment. The other half is an x-ray imager so the doctor can see what's going on while he's pushing a wire up your artery. The manager of the Q-Cath project and I teamed up to develop and sell a digital cineloop machine that would record 512x512 8 bits/pixel gray scale images at 60 frames/sec, fast enough for pediatric use. The platform was a 133MHz Pentium processor with 128MB of RAM running Windows NT. An Imaging Technologies IC-PCI image acquisition card DMA'ed images to RAM while a dual-controller PCI SCSI card wrote them out to the raw sectors of four fast 2GB SCSI drives. The 30K line program also imported and exported video in the medical DICOM format. The system was impressive for 1996. We hoped to sell it to Quinton but the company was taken private before we could finish negotiations and the new management dropped the entire Q-Cath product line shortly after.
Digital Imaging and Communications in Medicine (DICOM) is a complex standard for handling, storing, printing, and transmitting medical imaging information. The digital cineloop machine project needed DICOM support to be marketable so I wrote 28K lines of API and demo programs.
DICOM gray scale images stored in the little-used lossless JPEG format, which is basically Huffman, encoded delta values. Decoding lossless JPEG is slow, annoyingly slow on the hardware of the time. I developed a JPEG decoder that may be unique in that it precalculates a state machine for a given Huffman tree and then decodes the compressed image a byte at a time. Each compressed byte is used as an index into a jump table and up to eight uncompressed pixels are immediately written out with an average of about three machine instructions per pixel.
Map: A tool to draw maps from surveying data
One of my hobbies is surveying. I wrote an ambitious program to generate contour maps from surveying data. The program:
The large sparse matrix includes constraints to ensure the elevation and slope is the same along each shared triangle side. I tried many different equations to do this and ended up adding a primitive symbolic equation processor to the program to remove my error-prone hand derivations.
Unfortunately the program does exactly what I specified but not exactly what I want. It tends to extrapolate elevation and create peaks and valleys that are not justifiable. It works great for map-making however. If one takes care out in the field, the program can accurately locate points by triangulating bearing observations.
This map uses bearing observations to chart a trail network inside a lot:
This map reconstructs a surveying chart with bearing and range data:
Voyager planetary probe color composite image generator
Around 1990 NASA and the JPL released a set of CD-ROMs containing all the imagery from the two Voyager planetary probes. This gave me the opportunity to do something I wanted to do ever since I was a nerdy little kid and saw the images in Sky & Telescope magazine - make my own color composites.
First I wrote a program to decompress the Huffman encoded monochrome images and print out thumbnail images in order to see what was on the CD-ROMs. The DOS-extended compositing program had a graphical GUI and used a mouse to manipulate images and slidebars. The process had a number of steps:
The program worked and I'm quite proud of it. I ran it on a 20MHz 80386SX notebook with 8MB of RAM and a 40MB hard disk drive. If I were to revive the program I'd save the intermediate images with floating point intensity values instead of always reducing them to eight bits. I think the reductions caused graininess.
One of the composite images is here:
Expanded memory executable linker
The original IBM PC design was limited to 640KB of RAM. An early attempt to add more RAM mapped it into one or more 16KB banks high up in the original 1MB address space. This was called expanded memory.
One of Vermont Creative Software's products is the Vermont Views Designer, a WYSIWYG text mode form designer. At one time the Designer was getting large enough to limit the number and/or size of the forms loaded into memory and I was tasked with investigating whether expanded memory could solve the problem.
I did it two ways. First I modified the Designer to load forms into expanded memory. That was straightforward exercise in replacing pointers with handles and then dereferencing them. Then I wrote a linker that loaded the Designer program itself into expanded memory. The linker scanned the object modules and packed "close" functions, those that called each other, into 16KB chunks. Calls to close functions were handled by the regular CALL instruction. Calls to "far" functions, those on a different 16KB chunk, were redirected to a table in low RAM that called the expanded memory API to map in the appropriate chunk and then jumped to it. All data was kept in low RAM.
I did this work seconds before the first of the DOS extenders came out and obsoleted it.
Microcom Networking Protocol
The Microcom Networking Protocol (MNP) was one of several error-correcting protocols competing for standardization in the early days of modems. I was hired to add it to a new line of 2400bps modems by Anderson-Jacobson. First I designed a Z80 co-processor card that stood between the data terminal equipment (DTE) and the modem, and then I implemented the MNP protocol on it in assembly language. The implementation centered on a little cooperative multi-tasking kernel with high and low priority process queues.
Interesting bits were "AT" detection and calculating the optimum frame size.
Hayes compatible modem commands all begin with the characters "AT". Normally the start bit of the "A" is measured to determine the DTE's bit rate and the rest of the "AT" waveform is ignored. The co-processor board matched the complete waveform and determined the DTE's speed, character size (7 or 8 bit), parity and stop bit settings. In the process of writing this I discovered that there are two combinations of settings that are indistinguishable from the "AT" waveform.
An optimization one can add to an error-correcting network protocol is adjusting the frame size for the error frequency. If the transmission line is noisy then small frames are less likely to be corrupted but small frames also have a greater percentage of overhead. I derived an equation to determine the optimum frame size for a given error rate. It involves a square root operation so I included a little look-up table in the ROM. Later I found a much more rigorous version of the equation in my copy of Tanenbaum's Computer Networks.
The MNP protocol lost the standardization battle in favor of what became v.42bis. Information on the MNP protocol is available at:
DSP 300 baud modem
My first job out of school was working on an innovative eight-bit ISA voice card that had a telephone jack in addition to microphone and speaker jacks. The application program included voice record/playback, telephone answering machine, and voice recognition functions. I was responsible for maintaining the original on-board 8086 and TMS32010 processor programming.
As I got more familiar with the on-board code I started enhancing it and wrote, as a proof of concept, a 300-baud modem. The signal processor generated DTMF tones for dialing, detected dial, ring, and busy tones; and generated and decoded the two 300-baud data tones. The on-board 8086 handled "AT" modem command processing. A host Terminate and Stay Resident (TSR) program provided an INT API to an emulation of an 8250 UART. I then hacked a popular terminal emulator program and replaced the IN and OUT instructions to the UART with INT calls to the TSR. It was a very cool system. Later I reused some of the code and wrote a single-line voice mail system.
The voice card was far ahead of its time and wasn't widely sold. ITT Information Systems made a TV commercial featuring the card but it was more of a "Look how innovative we are." ad than a "Buy this product." ad.