Obviously, this never made it to production.  At this stage of my life, I had no concept of entrepreneurship.  What I did have was a need to send and receive information and too little money to purchase a serial card, so my only choice was to build my own.

I had an Intel 8251 somebody had given me and plenty of spare time.  At that time, semiconductor manufacturers were happy to send databooks to anyone who wrote and asked for them (Long distance was expensive) and DigiKey and Jameco were already in business, so all it took was some time with the databooks and a career was born.

Every ten years or so, I tell myself I should go out to the shed, dig out one of the old Apple IIs and see if any of them run.  If one did fire up, I could use my serial card to send all my old 6502 source files to a PC.  Why?  I don't know.  But the older I get, the more the idea intrigues me.

It has a place on the shelf in the lab and still gets used now and then when some non-critical signal needs a bit of amplification.

Radio Shack expressed an interest in selling a stripped-down version of this product, but the president of the company that built it refused to negotiate the price.  He wanted to get rich off the one deal with Radio Shack, and when that deal fell through, his company went bust.  Radio Shack eventually had its own version designed, but it was not nearly as good as this one.

Several Asian companies knocked off the whole design.  They even copied the aberration of the character "Z" in the dot matrix data, which was inserted purposely to detect knockoffs (Z was never printed).

If you look closely at the date on the EPROM, the firmware was last modified in May, 2002.  The board in the photograph is a spare, but a similar unit has been in continuous service for the past 38 years.

Needless to say, the Internet killed this technology in short order.

I modified the firmware so that it would decode any IR pulse stream and report it to the PC as an ASCII packet, giving the period in microseconds between each rising and falling edge.

The unit in the photo was pulled down off the shelf, dusted off and used to decode some IR codes for a project in July, 2022, almost exactly 31 years after its creation.

There was a 4-channel predecessor and the basic design was adapted to create an FXO version.  All cards can be configured for loop or ground start.

Both the DSU and CSU build options of the board are shown.

• +5 volts for digital logic
• +5 volts for analog circuits
• -5 volts for analog circuits
• -28 volts POTS talk battery
• 86 VAC RMS 20Hz ringer voltage

Total development time, from conception to working product, was under 2 months.  The first prototype board (shown in the picture) was fully operational at first power-up, requiring no changes to hardware or programmable logic.

The layout guy used the wrong library part for the processor and I had to "adjust" it on the first prototype (see inset image).  Otherwise, this was a boring and uneventful project.

Unfortunately, funding was cut just before the first batch of prototypes was to have been built, so the project was canceled.

The first board powered up and ran, with fully operational debug capability.  No changes to hardware or programmable logic were required.  Less than one hour of software debug at the first Beta install site and one firmware upgrade in the field resulted in a completely functional unit.

I was brought in to bring up the first board, create the critical ISR prolog and epilog code and write start-up code and drivers.

Once this had been handed off to the supplier, the Big Car Company's bloat code would not run because the supplier's prolog for the main control loop ISR was taking 20us, leaving too little time for the task to execute.  Their story was this was the fastest it could possibly be.  My code was taking 650ns, worst case, so, their incompetence exposed, they had to reconsider.  Eventually, they got it down to 12us, which was still utterly incompetent.

I wrote all the code, which was necessary due to having the control loop run at 50KHz switching frequency. The control engineers gave the algorithms and I smashed them into the 20us available. The result was a multitude of patents awarded.

The controller board was designed for a new dual-core processor and was going to be used to control two motors with a single microprocessor, but due to delays in production of the processor, the whole 2-motor project was on hold.  And because there was no funding available to design a new controller for the 5-phase project, that project was also on hold.  It was my suggestion that a batch of 2-motor boards be built with the older, single-core processor that got this program going again.

Bloat code from the control engineers caused the fast loop to run too slowly.  The algorithm I derived for fast estimatiion of a critical 5-phase control parameter during field weakening overmodulation led to my first electric vehicle patent.

Two patents were granted for optimizations of the control code and one was pending for PWM generation when my association with the Big Car Company ended.

If this board looks similar to the one below, it is.  Once again, it was my suggestion to repurpose this same controller board for this project.  Otherwise, the Big Car Company would have wasted months and thousands of dollars on creating a dedicated controller.

The prototypes performed well and I showed them how to adapt two instances of their single-motor bloat code, produced on a Linux server farm (using a process which has not changed since 1982), to run on a single processor.  But in the end the lawyers prevailed.  It was determined that cost and complexity savings were not worth the risk of having a single-point failure take out both traction motors.

I did get a patent for my code merging scheme, however.

The official decision-makers came up with a plan to saw the sensor wheel off the end of a crankshaft and mount that on a bearing in a special fixture with the reluctance sensor from the engine.  That was a great plan (especially for those who appreciate steam locomotives and Harley-Davidsons), but I needed simulation now, not two years from now, so I designed and built a simple little board that produced the signals with an 8-pin microcontroller.

Then, to compensate for doing something right, the Big Car Company closed down the research facility and integrated the work into its main powertrain development, which happens in a place where it gets down to -20 degrees in the winter.

Total software development time -- from nothing to fully functional and capable of driving a vehicle -- was three months.

If you can't buy what you want, build it.

• LED display for absolute brightness control
• Ambient light level brightness tracking
• Incrementally increasing alarm volume level
• AC power for reliable 60Hz reference
• RS-232 debug/status/programming interface
• No batteries (except for timekeeping during power outage)
• WWVB receiver
• Proximity sensor alarm control
• Simple and quick user interface
• Endlessly programmable forever
• Night vision brightness compensation

This board works well as a hydronic pump and blower controller, extracting maximum heat from the exchanger, but it was actually designed to be a general-purpose controller for any heating/cooling application, featuring four optically-isolated inputs, four solid-state relay outputs and significant breadboard area.  The unit in the picture has been retrofitted with a thermistor/ADC interface and flashing LED to indicate controller state.

New firmware was loaded into the controller and the board wired to the thermostat, in parallel with the FAU. With the board connected to a laptop, running software written to decode the simple serial data stream output by the monitor, every heat cycle is recorded with millisecond resolution.